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I-    I^IEODOCTION 

The  advent  cf  ccmputer  technology  daring  the  previous 
two  decades  has  affected  virtually  every  aspect  of  govern- 
nenr  and  private  industry.  As  technological  advances  fester 
the  availability  of  complex  systems  a-  lower  prices,  -he 
integration  cf  computer  systems  with  governmental  and  indus- 
trial processes  is  accelerated.  Applications  cf  coiiipu-cer 
systems  range  from  relatively  rou-me  data  processing  tasics 
such  as  payroll,  accounting  packages,  and  inventory  control 
to  intricate  scientific  systems  controlling  space  flights 
and  decision  support  systems  assisting  managers  in  resolving 
unique    problems. 

The  pervasiveness  cf  this  technology  has  created  many 
new  issues  for  management  concern  at  all  levels  cf  govern- 
ment  and  industry.  Among  these  issues  is  the  subject  of 
security.  As  systems  become  more  and  more  complex,  organi- 
zations which  utilize  thera  ara  becoming  more  and  more  depen- 
dent upon  them.  This  relationship  is  forci.ng 
compu tar-center  management  to  devote  efforts  toward  improved 
security  in  ail  areas:  hardware;  software;  communications; 
perscEnel;  and  administration  [Eef.  1].  It  is  useful  to 
consider  exactly  what  we  mean  by  the  term  "security"  with 
respect  to  ccmputer  systems.  According  to  Wylie,  security 
is  "a  state  of  mind  reached  when  one's  assets  are  receiving 
appropriate  protecticr.  Protection  has  three  facets  cf  equal 
importance.  Preventative  techniques  are  applied  to  prevent 
the  occurence  of  threats.  Detection  techniques  are  applied 
to  ensure  that  all  threat  occurences  are  registered. 
Finally,  for  every  threat  occurence  there  must  be  an  appro- 
priate response."  [Ref.  2]  These  definitions  present  a 
framework   on      which    a   computer      system    security    plan      may   be 


developed.  It  may  net  ba  possibls  to  design  a  system  which 
defeats  every  intrusion  attempx.  However,  an  adequate  goal 
for  many  organizations  might  be  to  raise  the  cost  cf  unau- 
thorized or  illegal  use  of  a  system  to  an  amount  so  high 
that  it  discourages  any  attempts.  While  this  goal  is  being 
pursued  viith  vigor  today,  contemporary  literature  is  replete 
with      examples    of      computer    crime.  The      U.S.      Chamber     of 

Commerce  estimates  that  if  computer  abuse  grows  proportion- 
ally with  the  number  of  computers  in  operation,  there  will 
be   roughly    $160    million   annual   loss    by    1985   [  Ref .    3]. 

Government  agencies  at  all  levels  and  private  enter- 
prises, especially  banks,  must  be  concerned  with  the  threat 
of  sabotage  and  disruption,  not  only  theft.  The  financial 
institutions  participating  in  •^he  electronic  fund  transfer 
sytem  (EfTS)  in  the  U.S.  handle  amounts  of  money  equal  to 
the  national  debt  every  four  days  [Ref.  U].  The  potential 
for  economic  disaster  of  enormous  magnitude  exists.  The 
motivation  to  prevent  large-scale  penetration  and  disruption 
of  systems  such  as  EJTS  is  providing  impetus  for  security 
research . 

The  need  for  computer  system  security  is  self-evident. 
The  magnitude  of  the  problem  is  enormous.  Partial  solutions 
to      this    problem      are  being      addressed   in      all  areas.  For 

example,  software  houses  have  developed  sophisticated  data 
access      control        packages.  Many      hardware        vendors      are 

including  some  type  of  security-control  feature  m  their 
products.  The  issue  of  computer  security,  however,  is  not 
confined  to  technical  considerations  alone.  Management  must 
become  intimately  involved  in  this  area  if  meaningful 
progress    is      to    be    made.  A   commitment    by      top    management, 

clearly  indicating  to  the  entire  organization  the  emphasis 
that  iiust  be  placed  upon  security,  is  necessary.  Management 
at  all  levels  must  be  involved  with  determining  policy  and 
implementing     measures      concerning     the      organization      of      a 
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computer  security  program,  security  admiri s^ration,  risk 
assessments,  personnel  practices,  and  back-up,  recovc-ry  and 
disaster    planning. 

The  federal  government,  including  both  civilian  and 
military  ag€ncies,  is  the  largest  user  of  ADP  facilities  in 
the  country  [Ref.  5].  Computer  usage  spans  a  vasx  diversity 
of  applications  such  as  World-Wide  Military  Command  and 
Conrrcl  System  (WWMCCS)  ,  Social  Security  Sysxem,  communica- 
tions, federal  payrcll  and  accounting  systems,  9tc.  This 
immense  usage  has  logically  gena-rated  interest  in  the 
security  of  these  particular  computer  systems.  In  fact,  the 
artenticn  being  devoted  to  the  security  of  computer  systems 
is  so  great  that  the  Office  of  Mandgeraent  and  Budget  estab- 
lished requirements  in  1978  that,  among  other  things,  every 
agency  inplement  a  computer  security  program.  OflE  also 
defined  a  minimum  set  of  controls  to  be  incorporated  into 
each    agency's  computer  security   program.      [Ref.    6] 

Ccntempcrary  literature  on  computer  security  seems  to  be 
in  agreement  in  expressing  the  view  that  the  best  approach 
to  computer  security  is  the  "total  systems"  approach. 
Critical  areas  which  must  be  examined  include  hardware, 
software,  users,  pr cgrammmers,  data,  input/output  documents, 
and    procedures.  Other    facets  of      a   system    pertinent      to   a 

particular  organization  may  also  need  to  be  examined.  One 
element  of  the  "total  systems"  approach  is  the  conduct  of  a 
risk    assessment. 

What  is  a  risk  assessment?  Many  texts  cffer  definitions 
which  differ  slightly  in  scope  and  degree.  Perhaps  the  most 
concise  and  applicable  is  Peter  Browne's  definiticn:  "A 
risk  assessment  is  an  analytic  process  designed  to  quantify 
the  DF  (data  processing)  security  required  by  an  organiza- 
tion. It  considers  the  threats  to  information  and  the  loss 
that  would  occur  if  a  threat  were  to  materialize."  [Ref.  7] 
The    results   cf      a  risk  assessment   enable      an   organization   to 
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consider  solutions  to  security  problems  which  ar=  ccst.- 
€ffectiv€.  The  solutions  may  eiz'asr  artempt  to  reduce  -he 
probability  of  threats,  lessen  the  effects  of  various 
threats,    cr   aid    in   the  recovery   from    a    "succsssf ul"   threat. 

An  organization  may  be  able  to  conduct  its  own  internal 
risk  assessment  if  personnel  assets  are  available. 
Specialists  in  computers,  security,  finance,  personnel  and 
operations  will  be  required.  Contracts  may  be  utili7ed  with 
one  of  several  commercial  companies  organized  to  conduct,  or 
to  provide  limited  assistance,  in  risk  assessments.  Chapter 
Three  will  address  this  issue  in  depth.  Of  course,  tne 
active   participation    cf   management  is    crucial. 

A   risk    assessment     is  a    dynamic   concept.  It    should   be 

revised  periodically  to  account  for  any  changes  in  equip- 
ment, software,  operating  procedures,  cr  any  different 
element  which  might  affect  the  overall  security  of  the 
system.  In  particular.         Naval     activities   with      computer 

systems  aie  required  to  update  their  risk  assessments  at 
least   evcry    five   years  [  Ref .    8]. 

The  federal  government,  as  well  as  business  enterprises, 
must  approach  the  security  problem  in  an  economical  manner. 
The  risk  assessment  provides  a  logical  framework  to  conduct 
a  rational  analysis.  Management  must  provide  guidelines  to 
reach   answers  to   the    following    questions: 

1)  What   are  the    specific    results    requirsd;    how    much 
security  is    required? 

2)  What  is    the    proper    balance   between    security    program 
cost  and   potential    benefits? 

3)  When  tradeoffs  can    be    mada   between    protection   and 
recovery,         hew    much      effort    should      be    expended      on 
each?      [Ref.    9] 

Obviously  the  minimum  amount  cf  security  needed  is  to 
protect  those  items  that  are  required  to  keep  the  organiza- 
tion   operating.  The  security      manager   should      incorporate 
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into  thr  security  plan  thoss  functions  which  are  supported 
by  computer  facilities  and  essential  zo  the  continued  opera- 
tion of  the  organization.  Additional  elements  may  also  be 
protected  if  it  is  economically  feasible  for  the  organiza- 
tion. A  cost-benefit  analysis  may  be  applied  re  the 
decision-making  process  concerning  additional  security 
measures. 

In  a  risk  analysis  situation,  it  is  necessary  to  iden- 
tify and  assess  the  degree  of  threat  against  the  computer 
resources  of  the  organization.  The  degree  of  threat  may 
determine  the  need  for  protection  of  some  asset.  The  amount 
and  cost  of  effort  tc  be  expended  in  examining  particular 
threats  should  be  proportional  to  the  potential  loss  caused 
by  such  thriats.  Threats  can  usually  be  grouped  into  one  or 
more    cf   the   following  categories: 

1)  natural    hazards   and    accidents    such    as    fire,    earth- 
quakes,   hurricanes,    etc. 

2)  internal   accidents    and   breakdowns   such  as    programmer 
and   operator   errors,    hardware    failures,    etc. 

3)  violent    intentional    actions   such   as   sabotage, 
strikes,    etc. 

U)  ncn-violant  intentional  actions  such  as  fraud, 
embezzlement,  and  theft.  £aef.  10] 
The  potential  loss  associated  with  each  threat  must  also 
be  examined  .  Some  consistent  quantifying  standard  must  be 
applied  to  each  threat  so  that  comparisons  between  losses 
can  be  made.  Similar  to  threats,  losses  may  also  be  grouped 
into    four   general   categories: 

1)  delayed  processing-  the  expense  incurred  when  a 
computer  application    is   not    processed    on   time    . 

2)  less  of  data  processing  assets-  these  are  the  orga- 
nizational assets  in  the  custody  of  the  data  processing 
unit.  Data  are  the  most  valued  assets  and  loss  of  data 
may   cause    irreparable    harm. 
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3)  less  of  organization  assats  by  means  of  coraputar 
applications-wh€n  assets  such  as  accounts  receivable, 
negotiable  securities,  etc.,  are  controlled  by  a 
computer,  they  are  vulnerable  to  fraud  and  manipala- 
ticn. 

U)    loss  of    data    confidentializy-    disclosure    of    personal 

cr    proprietary      data  to   unauchorized   persons      can   cause 

economic  loss,      dilution   of     planning   efforts,      loss   of 

employee  morale,    and  legal   action.      [Ref.    11] 

The    po-enxial      threats  and    t:he      losses    associated      wi-h   each 

threat    must    be    considered   together.         2ach    pairing    of   threat: 

and    less    should    te   ranked   according   -o    their    iapact    upon   -che 

organization.         After  this    ranking     has    been   developed,      th^ 

process   of      examining  cost-effective    countermeasures      can   be 

studied. 

This  chapter  has  provided  an  overview  of  the  nature  of 
the  computer  security  problem  today.  In  particular,  the 
concep-  of  risk  assessments  has  been  introduced  and  its 
potential  benefits  to  organizations  have  been  considered. 
The  subject  of  risk  assessment  and  related  ideas  will  be 
addressed  in  greater  detail  in  later  chapters.  Chapter  Two 
will  detail  the  history  and  evolution  of  risk  assessment 
requirements  within  the  Department,  of  Defense  and  the 
Department  of  the  Navy.  Chapter  Three  will  examine  various 
points  which  must  be  considered  when  an  organization  is 
deciding  whether  zo  do  an  "in-house"  risk  assessment,  cr  to 
contract  this  function  with  a  commercial  company.  A  general 
framework  for  conducting  a  risk  assessment  at  the  Naval 
Postgraduate  School  will  be  discussed  in  Chapter  Four.  The 
framework  will  be  based  upon  the  guidelines  promulgated  in 
OPNAVINSI.  5239. 1A.        Chapter      Five    will      examine    how      to 

design  a  decision  support  system  to  assist  management  in 
conducting  a  risk  assessment.  Basic  design  modules  will  be 
presented  and  some    particular      problems   associated    with   data 
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tase    fflanagement    will    ba   ccnsidersd.  Tha    field    of    ccmputar 

security  in  general,  and  risk  assessments  in  particular/  has 
advanced  to  such  a  degree  that  several  companies  new  offer 
automated  risk  assessment  sySwems.  A  brief  consideration  of 
these  systems  and  a  comparison  of  their  attributes  vis-a-vis 
manual  systems  will  also  be  presented  in  Chapter  Five.  The 
final  chapter  will  summarize  the  pertinent  points  covered  in 
this  thesis.  Some  conclusions  will  be  drawn  about  the  state 
of  risk  assessments  m  the  modern  organizational  environ- 
ment. Lastly,  some  recommendations  to  improve  the  effective- 
ness and  efficiency  of  the  risk  assessment  process  will  be 
presented. 
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II.     DEPABTSENT    OF    DE|ENSE/D  gPABTtlZNT    OF    THE    NA7I    DIRECTIVES 


A.       GENEBAL 

From  the  outset,  the  Federal  Government  has  beer,  a 
pioneer  in  the  development  of  advanced  corapurer  systems. 
"The  first  successful  large  scale  data  processing  installa- 
tion was  [r.ade  in  the  early  fifties  at  the  Census  Bureau,  and 
the  initial  impetus  toward  programming  languages  for  busi- 
ness applications  came  from  Department,  of  Defense  support  of 
the  COBOL  programming  language  in  the  sixties"  [Hef.  12]. 
From  that  point  en,  the  rapid  growth  of  computer  technology 
and  the  gcv=mraent's  reliance  on  accurate  computing  systems 
rose  at  an  exponential  rate.  Poor  accounting  and  managerial 
conircl  practices,  however,  have  brought  about  extreme  inac- 
curacies in  the  data  pertaining  to  computer  hardware  and 
software  inventories  held  by  the  Federal  Government.  In 
1976,  estimates  of  the  amount  of  money  spent  on  data 
processing  were  decidedly  vague.  "The  General  Accounting 
Office  (GAG)  was  able  only  to  bracket  Federal  Data 
Processing  spending  as  between  33  billion  and  $10  billion 
annually.  Mere  recently,  the  Office  of  Management  and  Budget 
(0MB)  has  cited  a  figure  of  $5.5  billion,  and  the  General 
Services  Administration  (GSA)  has  estimated  the  cost  of 
software  development  and  maintenance  alone  at  $2.2  billion." 
[Ref.  12]  A  large  percentage  of  these  expenditures  were 
attributed  to  the  DCD.  In  1931,  tae  number  of  installed 
computer  systems  was  estimated  to  be  around  15,000,  while 
the  number  of  personnel  working  in  the  computer  field  was 
estimated  at  100,000  [Ref.  12].  These  figures,  however,  are 
gross   approximations. 
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sines  the  scianc-a  cf  computer  tschnoloqy  was  a  rela^ivsly 
naw  phsriCnenon  at  thB  tiraa  zhs  governman-  began  -o  axclcrs 
its  pcssifcilities,  the  dayslopmant  oz  gov^rnmen-  coaiputar 
systems  was  done  in  a  rather  piecemeal  fashion,  with  little 
regard  to  the  managerial  aspects  of  designing  and  imple- 
menting computer  systems.  The  emphasis  was  on  buying/ 
davelcping  and  getting  rhe  systems  into  operation  as  fast  as 
possitle  in  ordar  to  show  that  a  functional  entity  nad 
resulted  from  all  rh-r  monetary  and  personnel  resources  thar 
had  been  expended.  As  a  result,  of  uhis  mismanagement  (or 
rather  ncn-management)  ,  governman"::  agencies  were  faced  with 
computer  systems  that  were  inflexible,  inaccurate,  and 
subject  to  rapid  obsclesence.  The  public  outcry  over  the 
amount  of  tax  dollars  spent  on  mismanaged  computer  resources 
led  the  Federal  Gcvernment  to  issue  policy  directives 
addressing  computer  management,  from  the  initiation  of 
requirements  analysis   to    final    test    and    implementaticn. 

B.       GCVEHNMENT    C0NCE5NS 

At  afccut  this  same  time,  there  was  a  growing  concern 
over  th=  security  vulnerabilities  inherent;  in  these  new 
computer  systems.  Although  hardware  and  software  technology 
had  been  progressing  at  a  rapid  rate,  little  consideration 
had  been  given  to  computer  security  technology.  However, 
with  the  ErcoJcs  Act  cf  196  5,  the  Office  of  Management  and 
Budget  (CMB)  had  been  assigned  r esponsibili-ies  for  the 
oversight  and  policy-making  functions  applicable  to  computer 
systems  development  and  acquisition.  Thus,  "in  1972,  --  0MB 
urged  private  industry  --  hardware  nianuf acturers,  software 
houses  and  related  service  industries  —  to  make  greater 
capital  investmer.xs  in  computer  security.  At  the  time,  the 
Federal  Government  v»as  concerned  that  its  inability  to 
protect    data      in   computer      systems  --      except   at      very    great 
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6xp9ns€  --  was  limiting  iis  abili-y  -o  realize  the  bei^efjits 
cf  tschnclogy. "  [Ref.  13]  In  Decamber  of  -hat  sans  y  =  ar, 
the  Department  of  Defense  issued  DDD  Directive  5200.23  enti- 
tled "Security  Requirements  for  Automatic  Data  Processing 
(ADP)  Systems".  The  purpose  of  the  directive  was  to  estab- 
lish "uniform  policy  for  protecting  classified  data  stored, 
processed,  or  used  in,  and  classified  information  communi- 
cated, displayed,  or  disseminated  by  an  Automatic  Data 
Processing    (ADP)       system"   [Ref-    14].  Although    DOD   5200.28 

does  not  directly  address  risk  assessments,  it  does  require 
that  the  heads  of  DOE  components  provide  for  the  appointment 
of  an  ADE  Security  Officer,  who  will  later  play  an  important 
role  in  conducting  rislc  assessments  for  Navy  computer 
facilities. * 


In  the  mid-1970* s,  0MB  became  even  more  concerned  with 
encouraging  the  growth  of  computer  security  technology  since 
the  Privacy  Act  of  1974  set  "forth  a  series  of  requirements 
governing  Federal  agency  personal  record-keeping  practices" 
[Ref-  15].  These  requirements  increased  the  need  to  provide 
security  for  the  personal  data  maintained  in  Federal 
computer    systems. 

C-       LEGISLATION 

The  Brcoks  Act  also  assigned  otner  agencies  responsibili- 
ties for  ccntributing  to  the  Federal  ADP  Programs,  The 
National  Bureau  of  Standards  (NBS) ,  under  the  Secretary  of 
Commerce,  was  tasked  with  providing  "leadership,  technical 
guidance,  and  coordination  of  government  efforts  in  the 
devalcpment      of    guidelines      and      standards"   [Ref-     19].  in 


iThe  terms  "Risk  Analysis"  and  "Risk  Assessment"  can  be 
used  interchangeably.  While  early  government  directives  used 
"Risk      Analysis",         it      is      new    more      common      to      use      "Risk 

Assessment" . 
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areas  pertaining  to  ADP  and  ADP  Security.  The  basic  philo- 
sophy brhind  the  NBS  work  in  ADP  security  was  reflected  in 
Federal  Information  Processing  Standards  Publication  (FIPS 
PUB)  31  of  June,  1974:  "Data  confidentiality  and  computer 
security  are  dependent  upon  the  application  of  a  balanced 
set  cf  managerial  and  technological  safeguards.  Within  -che 
context  of  a  total  security  program,  the  NBS  is  pleased  to 
provide  guidelines  for  ADP  Physical  Security  and  Pisk 
Management    avilacle    for   use    by   Federal   agencies"    [fief.    19]. 

The  ccncepr  of  Risk  Ma  nagemeni  was  introduced  at  this 
time  to  provide  federal  agencies  with  guidelines  for 
applying  management  principles  to  the  risks  associated  with 
the  acquisition  cf  hardware  and  software.  Although  FIPS  PUB 
31  specifically  addresses  physical  security  programs,  it 
also  touches  upon  procedural  aspects,  contingency  planning, 
supporting  utilities,  computer  reliaoility,  disaster  prob- 
abilities, security  awareness  programs,  and  risk  analysis 
methcdolcgies.  This  publication  was  one  of  the  first  to 
provide  specific  recommendations  on  implementing  comprehen- 
sive computer  security  programs.  It  is  important  to  note, 
however,  that  its  contents  were  strictly  composed  of  recom- 
mendaticns  and  guidelines  -  they  did  not  constitute  a 
government  directive  mandating  computer  security  require- 
ments on  government  agencies.  The  publication  was  edited  by 
Susan  K.  Reed  of  the  Systems  and  Software  Division  of  NBS. 
She  later  authored  a  government  document  on  conducting  risk 
analyses  which  would  be  included  as  an  addendum  to  DOD 
5200. 28-M,  the  Department  of  Defense  ADP  Security  ilanual. 
This  lanual  will  be  discussed  in  more  detail  in  a  subsequent 
section. 

It  is  interesting  to  note  that  FIPS  PUB  31,  published  in 
1974,  covers  in  great  detail  those  security  practices  that 
are    advocated  by   more      recent    publications.         Unfortunately, 
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the  publication  has  te^n  overshadowed  by  currenr  dizrctives 
that  dictate  what  must  be  done  but  nox  how  to  do  i*.  For 
example,  conventional  risk  assessments  require  an  analysis 
of  the  fctential  threats  to  an  ADP  facility  caused  by  wind- 
storms, hurricanes,  and  tornadoes.  Such  informa-icn  could 
conceivably  be  obtained  from  the  National  iieather  Service, 
but  it  is  already  provided  in  FIPS  PUB  31.  In  Key  West, 
Florida,  zc  be  specific,  the  annual  probability  that  a 
hurricane  will  occur  is  13%  [Ref.  20].  This  figure  could  be 
used  as  direct  input  to  the  threat  analysis  form  for  the 
current    CCD-advocated  risk    assessment    methodology. 

To  start  a  security  prcgrara,  the  FIPS  encourages  all 
government  agencies  tc  "perform  a  preliminary  risk  analysis 
to  identify  major  problem  areas  and  select  interia  security 
measures  as  needed  to  correct  major  problem  areas" 
[Ref.  21].  The  idea  behind  this  is  that,  sinca  computer 
security  is  an  cngoing  process,  the  most  obvious  security 
problems  should  be  handled  in  an  expeditious  manner  -  agen- 
cies need  net  and  should  not  wait  until  a  comprehensive  risk 
assessment  has  been  ccmpieted  prior  to  tackling  the  serious 
security  frcblems.  In  the  meantime,  a  preliminary  assess- 
ment   should    be    done    to  help    isolata    those    problems. 

The  actual  risk  assessment  methodology  presented  in  the 
FIPS  is  a  scund  one.  It  gives  an  excellent  overview  of  the 
means  by  which  a  risk  assessment  may  be  conducted,  complete 
with  charts,  tables,  and  figures  that  the  user  may  apply  in 
calculating  the  final  Annual  Loss  Expectancy  (AL2)  value. 
However,  the  publication  is  somewhat  weak  when  it  comes  to 
describing  the  format  or  layout  of  an  agency's  actual  risk 
assessment    document. 
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D.  DEFIKITIONS 

Before  gcing  into  ths  specific  risk  asssssraen-,  a'=-hci- 
ology  outlined  in  the  FIPS,  it  is  appropriate  to  define 
certain  terms  which  ars  common  to  mosz,  if  r.ct  all, 
government-endorsed    risk   assessment   methodologies    : 

IHREST  -an  overt  or  covert  activity  which  may  cause 
less   or  damage    tc  a   computer  facility; 

LOSS  -the  potential  for  being  deprived  of  computer 
assets   or    services; 

VOLNEBABILITY  -the  weakness  inherent  in  a  computer 
system,   which    makes   it    susceptible   to   loss   or    damage; 

ANNUAL  LOSS  EXPECTANCY  (ALE)  -an  estimate  oi  the  airount 
cf  money  that  a  computer  facility  could  potentially 
lose  in  a  year  if  threats  against  the  facility  were 
realized. 

E.  FIPS    POB    31     METHODOLOGY 

The  FIPS  methodolgy  is  basically  a  three-step  process  : 
1.)  Make  an  estimate  of  the  potential  losses  to  which  the 
computer  facility  is  exposed;  2.)  Perform  an  analysis  of  the 
threats  which  may  be  made  against  the  facility;  ^nd  3.) 
Combine  the  estimates  of  potential  loss  and  probability  of 
loss    tc    produce    an    ALB   value. 

^  •      Hstimatinq    Less 

Step  one,  estimates  of  potential  losses,  is  to  be 
done  in  terms  cf  five  distinct  categories  :  "(1)  physical 
destruction  or  theft  of  physical  assets;  (2)  loss  or 
destruction  of  data  and  program  files;  (3)  tneft  of  informa- 
tion; (4)  theft  of  indirect  assets;  and  (5)  delay  or  preven- 
tion  of   computer   processing"   [  9ef  -   21].      The    end    products  of 
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this  procedure  are  an  iden- if icarion  of  the  comparer  facili- 
ty's   assets    and    dollar  values    for   loss   estimates. 

Cf  the  five  categories  listed,  the  first  is  undoub- 
tedly the  mcst  straightforward.  Replacemenu  costs  for  such 
items  as  hardware,  ccmmunications  equipaent,  supplies,  and 
the  building  itself  should  be  entered  into  -he  command's 
inventory   files      as    required   by   QSk.  Unf cr-.unately,      many 

federal  agencies  have  neglected  to  maintain  inventory  files 
over      the    years.  One   of      the      fringe    benefits      of   a      risk 

assessment  is  that  such  inventories  mus*  be  generated,  thus 
enhancing  a  command's  resource  managemen*:  capabilities. 
Once  these  inventories  have  been  made  available,  the  esti- 
mate cf  less  for  a  particular  piece  of  equipment  corresponds 
to  its  replacement  cost.  For  example,  if  a  high-speed  line 
printer  costs  $5000 ,  then  its  loss  estimate  would  be  the 
same  -  the  command  has  the  potential  for  losing  $5000  if  the 
printer    were  to    be    destroyed   or   stolen. 

In  the  second  and  third  categories,  less  or  destruc- 
tion of  data  and  program  files  and  theft  of  information,  a 
great  deal  cf  ambiguity  occurs.  The  question  wnich  must  be 
answered  is  :  what  is  the  value  of  the  data  contained  in  the 
computer  system  ?  This  is  a  question  which  has  received  a 
great    deal      of    attention    in      recent    years.  The    Commander, 

Naval  Data  Automation  Command  (C0MNA7DAC) ,  spent  a  signifi- 
cant amount  cf  time  and  money  in  trying  tc  bring  the  ques- 
tion of  the  value  of  data  into  perspective.  Seme 
consideration  was  given  to  standardizing  data  value  based  on 
the  number  cf  lines  cf  code  and/or  security  classification. 
A  single  line  of  code  in  a  100-line  program  file  might  be 
valued  at  $10,  fcr  example.  The  loss  or  destruction  cf  the 
file  would  thus  contribute  $1000  to  the  agency's  ALE.  In 
essence,  it  would  cost  the  command  $1000  to  reconstruct  the 
file.         In   a  similar   manner,      a   word    of    SECRET  or    lOP   SEC2ET 
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ccd9,  if  compromised  or  sroler.,  might  be  valued  at  ilOO  and 
$200  respectively.  Ey  standardizing  these  values,  ccmputing 
the  5LE  for  most  types  of  computer  software  would  be  a 
simple  matter  of  mathematical  calculation,  with  lines  of 
code  (the  amount  of  money  it  would  cost  a  programmer  to 
reproduce  the  code)  being  an  absolute  value,  and  classified 
code  representing  a  relative  value.  In  theory,  s-'ich  aethcds 
have  a  sound  basis.  In  practice,  however,  the  application 
of  such  methods  has  proven  to  be  rather  unrealisxic.  In 
fact,  CCMNAVDAC  has  recently  abandoned  :.ts  attempts  to 
provide  for  standardization  in  favor  of  more  practical 
methcds. 

"If  zhe  ADP  system  is  used  to  control  other  assets 
such  as  cash,  items  in  inventory,  or  authorization  for 
performance  of  services,  then  it  may  also  be  used  to  st.sal 
such  assets."  [Ref.  22].  These  assets  are  known  as  indi- 
rect assets,  and  their  loss  estimate  corresponds  to  the  real 
value   of   the  asset. 

In  estimating  the  potential  loss  caused  by  t.he  delay 
cr  prevention  of  computer  processing,  several  considerations 
mus-  be  addressed.  Some  losses  may  be  est;ijiaxed  in  a  rela- 
tively straightforward  manner.  Obvious  examples  involve  a 
failure  to  process  payment  checks  promptly,  thereby 
preventing  the  exercise  of  a  prompt  payment  discount  under  a 
procurement  contract,  or  delays  in  an  inventory  system  which 
may  lead  to  idle  manpower  at  a  warehouse  [Ref.  22].  In  a 
situation  where  a  computer  facility  functions  as  a  service 
agency,  the  loss  estimate  would  be  based  on  the  revenues 
lost  as  a  result  of  the  customers  being  denied  access  to  the 
computer  sysxem.  On  the  other  hand,  "...in  those  situations 
where  a  delay  would  more  or  less  halt  operations  of  an 
agency, .. .use  the  daily  operating  cost  of  an  agency  as  a 
rough  rule-of-thumb  estimate  of  the  cost  of  delayed 
processing"    [Ref.    22]. 
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In  gsr.eral,  -here  are  time  ranges  or  limits  within  which 
loss  estiicates  will  differ.  If  service  is  denied  but  -.he 
system  can  te  brought  back  up  witain  a  reasonable  amcun-  of 
time,  it  is  possible  that  no  loss  will  be  incurred  during 
that  time  p=riod.  However,  after  a  certain  p^ricd  of  rime 
during  which  the  computer  system  has  noz  been  returned  to 
service,  losses  will  be  incurred,  and  in  general,  such 
losses  will  grow  in  proportion  to  the  duration  of  the  delay. 
The  FIFS  PUB  stresses  the  importance  of  establishing  "his 
"maximum  'no  loss*  delay  time  and  an  estimate  of  rhe  iiedian 
time  to  reconstruct  the  AD?  facility  after  total  destruc- 
tion"  [ Ref .    22].         Once  these   time/cost    boundaries    have   been 
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made,         then  the      time   period      can   be      divided   into      various 
ranges   and    less    estimates  can    be    assigned    accordingly. 

After   conducting  a  preliminary      estimate   of  all    potential 

losses,         the  task  might    be      simplified      by    presenting      the 

collected      data      in  tabular      form,       as      shown      in      Table      I 

extracted   from    FIPS  FUB    31. 
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2  •      Syaluat inq    Threats 

In  proceeding  with  th€  sscond  step  of  th9  risk 
assessment,  that  of  evaluating  the  threats >^ainst  th?  ADP 
facility,  the  ADP  Security  Planner  (i=.  the  person  respon- 
sible for  conducting  the  overall  risk  assessment)  should 
solicit  the  help  of  fire  marshals,  hardware  vendors,  other 
govercment  agencies,  in  house  personnel,  and/or  any  agency 
or  person  who  might  contribute  inputs  to  a  threat  evalua- 
tion. Table  II  provides  a  list  of  sources  of  information 
for    different  categories   of    threats. 

although  the  FIPS  gives  little  information  on  the 
specific  numerical  figures  to  use  in  quantifying  threats,  it 
does  provide  specific  guidance  on  determining  threat  crcb- 
abilities.  Figure  2.1,  for  example,  a  seismic  risk  map  of 
the  United  States,  gives  the  user  a  rough  idea  of  the  long- 
term    hazards  caused    by  earthquakes. 
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3-      Calculating    the    Annual   Loss    ExQactancy    (ALE) 

The  final  step  in  the  risk  assessment  prcc=ss 
itself,  although  follow-on  action  is  understood,  involves 
the  detezniination  of  the  ALE.  This  can  be  accomplishsd  (and 
most  readily  und=rstcod)  by  constructing  a  matrix  of  -hreats 
and  the  Icsses  vhich  might  be  associated  wi-h  them.  Table 
III  shows  a  computation  for  estimating  the  expected  Icsses 
that    night    te  caused    by    fire    damage. 

Construction  cf  such  a  table  is  a  ccmmcn  procedure 
in  cperaticns  research  and  aanagement  sciences  where  the 
objective  may  bs  to  ainimize  losses  (as  in  this  case)  or 
maximize  profits.  The  occurrence  probabilities  shown  (.10, 
.05, .005)  may  be  derived  by  analyzing  the  facility's  fire 
safety  precautions,  a  procedure  for  which  the  FTPS  PUB  gives 
detailed   guidance. 

The  dollar  amounts  for  loss  may  be  computed  as 
described   earlier  in   the   chapter.  Once   these   figures  have 

been  made  available,  estimates  for  the  total  potential  loss 
and  the  annual  loss  for  each  category  can  be  calculated  by 
multiplying  the  occurrence  probability  by  the  loss  figures. 
Similar  tables  can  be  constructed  for  natural  disasters  such 
as  earthquakes,  tornadoes,  volcanic  eruptions,  floods,  and 
others. 

Open  completion  of  the  estimation  of  the  ALE  for  all 
categories  cf  less,  the  security  manager  should  have  a 
clearer  understanding  of  the  coupling  of  threats  and  Icsses 
within  his  facility.  He  is  then  in  a  position  to  prioritize 
his  work  in  the  area  of  computer  security  ccuntermeasures. 
In  general,  remedial  measures  should  be  applied  to  those 
areas  in  which  the  loss  potential  is  the  greatest.  The  end 
result,  then,  of  the  risk  assessment  process  is  a  cost- 
benefit   analysis      of   expending   funds    towards     th=    "securing" 
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TABLE    III 
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acinor  9tr« 
la  ADP  Ana 

Uajor  Tire 
la  Bide 

Total 
Lam  Flr« 

ooo 

ao6 

.0006 

Bnlldln^  Damage 
ADP  Hardwars 
Gcseni  Sqntp. 
Supplies,  etc. 
Task  D— Delay 
Task  B— Delay 
Taak  7— Delay 
SM1«  Seeonstnict 

no,ooo 

50.000 
5,000 

10.000 

5.000 

12.000 

5.000 

S100.000 

10.000 

7.00O 
20.000 

».700,000 

2aoo,ooo 

286,000 

130.000 

36.000 

loaooo 

250,000 
S0.00C 

Tod 

il  potential  1o*^          ,   , 

97.000 

137,000 

S.686.000 

Ajlfl 

nill   Inaif 

S  9,T00 

i    9,800 

1       3,342 

• 

cf  a  specific  computsr  security  weakness.  If,  for  exaipis, 
the  ALE  fcr  building  damage  cajsed  by  fire  is  $  9,700  ,  the 
agency  should  be  willing  to  spend  up  zo  -hat  amcunt  in 
providing  remedial  measures  to  lessen  that  loss  potential. 
The  risk  assessment  will  thus  provide  tne  security  manager 
with  the  ammunition  he  needs  to  get  top  management  support 
on    funds    fcr  security  countermeasures. 

The  preceding  synopsis  of  the  FI?S  methodology  might  seem 
to  De,  as  presented,  a  relatively  straightforward  process. 
However,  the  FIES  FOB  clearly  states,  "...this  is  not  an 
exact  science.  Indeed,  it  is  quite  likely  that  cne  will 
have  to  reappraise  threats  and  losses  more  than  once, 
concentrating     on   the     areas      initially      identified   as      most 
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critical,  before  the  less  expectancy  estimate  reacn^s  a 
satisfactory  level    of  confidence."     [  Ref -    23] 

The  level  of  detail  provided  for  the  above  FIPS  PUB  meth- 
odology will  serve  as  a  point  of  reference  for  descriptions 
of  subsequent  methodclogies .  Other  risk  assessment  metho- 
dologies will  be  discussed  in  terms  of  how  they  differ  from 
the   one   described  in    FIPS   PD3    31. 

F.       SOBSZQOENT    GOVERNMENT    DIRECTIVES 

Shortly  after  the  release  of  FIPS  PUB  31,  the  Privacy  Act 
of  197a  was  enacted.  O.'lB  Circular  A-108,  distributed  six 
months  later,  was  written  to  assign  responsibilities  for  the 
security  cf  the  personal  records  maintained  by  Federal  agen- 
cies. Under  this  directive,  the  term  "system  of  records" 
was  defined  as  "...a  group  cf  any  records  under  the  control 
cf  any  agency  from  which  information  is  retrieved  by  the 
name  of  the  individual  or  by  some  identifying  number, 
symbol,  or  other  identifying  particular  assigned  to  the 
individual"  [Ref.  16].  Since  computer  and  word  processing 
systems  are  perfect  vehicles  for  data  storage  and  retrieval, 
it  was  and  is  only  natural  that  they  would  be  used  for  the 
maintenance   of       personal    records.  A-108    further      mandated 

that  reasonable  administrative,  tecnnical,  and  physical 
safeguards  are  established  to  ensure  that  personal  records 
are  only  disclosed  to  those  who  are  authorized  to  have 
access  to  them  [Ref-  17].  This  implies  that  security  coun- 
terraeasures  must  be  in  effect  for  ail  federally-owned 
computer  systems  maintaining  personal  data-  The  directive 
also  required  that  the  GSA  "revise  computer  and  telecommuni- 
cations procurement  policies  to  provide  that  agencies  must 
review  all  proposed  equipment  and  services  procurements  to 
assure  compliance  with  applicable  provisions  of  the  Act" 
[Ref.    18].      This  was    the   first    of   many    government    directives 
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£^5iiilii:a  "that  federal  agencies  address  security  issaes  in 
their  ccmpater  develccaer.t  and  acquisition  plans.  Hctf=ver, 
outside  of  FIPS  PUB  31,  the  distribution  and  knowledgs  of 
which  was  very  limited,  -he  Federal  Governmenr  was  slew  to 
document  specific  policies  and  procedures  for  iaplemer.'iing 
computer   security   programs. 

Finally,  three  years  later  in  July,  1978,  O^IB  Circular 
A-71,  entitled  "Security  of  Federal  Automated  Information 
Systems",  was  approved  for  distribution.  In  ganaral,  the 
purpose  of  A-7  1  was  to  promulgate  "policy  and  responsibili- 
ties for  the  development  and  implementation  of  computer 
security  programs  by  executive  branch  departments  and  agen- 
cies" [Ref.  24].  This  circular  documented  the  requirement 
that  pericdic  risk  assessments  be  conducted  by  each  federal 
agency      operating      a      computer        facility.  Although      A-71 

provided  no  guidelines  on  how  to  conduct  a  risk,  assessment, 
it  did  require  that  a  risic  assessment  be  carried  cut  or 
revised    under  any   of   the    following  conditions    : 

1.)  prior  to  the  approval  of  design  specifications  for 
new    computer    installations; 

2.)  whenever  there  is  a  major  change  to  the  physical 
facility,    hardware  or   software;    or 

3.)  at  periodic  intervals  of  time,  not  exceeding  five 
years,  if  no  risk  assessment  has  be£ii  performed  dur- 
ing  that    time. 

[Hef.    25] 

This  directive  had  serious  consequences  for  all  federal 
agencies.  For  most  agencies,  the  third  condition  was  the 
one  under  which  the  risk  assessments  would  be  conducted. 
Those  agencies   which  had  yet   to  perform  a   risk  assessment 
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interpre-t-id  the  condition  as  meaning  -hat  they  had  a  five- 
year  deadline  on  the  requirement;.  Unf ort'inazely ,  rhis 
slowed   response    from   many   federal   agencies. 

To  promulgate  the  requirements  of  A-71,  the  Department  of 
the    Navy      issued  OPNAVINST      5239.1    in      April,      1979.  This 

instruction  specified  the  A-71  requirements  for  all  DON 
activities.  Although  the  instruction  did  little  to  augment 
the  policies  provided  by  A-71,  it  did  require  that  all  DON 
activities  operating  computer  installations  appoint  an  AD? 
Security  Officer  who  would  be  responsible  for  ensuring  that 
a  risk  assessment  would  be  conducted  on  a  periodic  basis. 
Two  relevant  enclosures  that  were  included  as  part  of 
CPNAVINST  5259.1  were  DOD  5  200.28-M  entitled  "Techniques  and 
Procedures  for  Implementing,  Deactivating,  Testing,  and 
Evaluating  Secure  Resource- Sharing  ADP  Systems",  and  a  set 
of  guidelines  for  conducting  risic  assessments  which  was 
edited  by  Susan  K.  Heed.  The  former,  constituting  the  DOD 
ADP  Security  Manual,  provided  standardized  guidelines  for 
securing  computer  systems  -  it  did  not  address  risk  assess- 
ments; the  latter,  however,  provided  an  excellent  generic 
framework  for  conducting  risk  assessments.  It's  merit  was 
more  in  facilitating  the  security  officer's  understanding  of 
the  risk  assessment  lodel  than  in  the  actual  methodolgy 
proposed.  The  technique  presented  by  the  methodology  is 
similar  to  that  presented  in  FTPS  ?(J3  31,  but  is  a  more 
mathematically-oriented  model.  These  guidelines  were  later 
released  in  August,  1979,  as  FIPS  PUB  65,  "Guideline  for 
Automated    Data    Processing   Hisk   Analysis". 

G.       FIPS    PDB   65     METHCEOLOGT 

In  general,  FIPS  PUB  65  "explains  the  reasons  for 
performing  a  risk  analysis,  details  the  management  involve- 
ment   necessary    and    presents    procedures      and   forms   to    be   used 
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for  risk  analysis  ard  cost  effective  svaluation  cf  saia- 
guards"  [R9f.  26].  Onlike  FIPS  PUS  31,  this  NBS  publication 
giv9s  no  guidance  on  estimating  specific  loss  prcfcatilities 
(i€.  there  are  no  seismic  risk  maps  or  tables  with  hurricane 
probatilities  for  various  regions)  ,  but  it  does  provide  a 
better  and  more  detailed  explanation  of  the  quantitative 
measures      and   forms      required    for      a      zisK.    assessment.  In 

short,  FIFS  PDB  65  covers  the  ambiguities  present  in  FIPS 
FUB  31.  The  two  in  ccmbinaticn  provide  a  powerful  framewcrk 
under    which   a   viable    risk  assessment    can    be   conducted. 

Like  most  methodologies,  the  one  advocaxad  by  FIPS  PUB  65 
reccicirends  that  a  prelicninary  security  analysis  be  perfomted 
in  order  to  identify  a  computer  installa-^ion  •  s  assets, 
threats,  vulnerabilities,  and  thus,  the  facility's  security 
posture.  Three   specific      products    will      result    frcm     this 

preliiBinary   analysis    : 

1.)    a    list   of  asset   replacement  costs; 

2.)    a    list  of   threats   to    which   the    facility   is    vulner- 
able;  and 

3.)    a    list   of  existing  security  measures.      [Hef.    27] 

These  products,  once  assigned  quantitative  measures,  will 
form    the    basis    for    the  computation  of   the    ALE  (s)  . 

The  next  step  in  the  FIPS  methodology  is  to  quantify  the 
measures  for  impact  and  the  frequency  of  occurrence  for 
threats.  The  impact  cf  an  event  is  defined  as  the  exact 
amount  cf  damage  it  could  cause,  while  the  frequency  of 
occurrence  refers  to  the  exact  number  of  times  xhe  event 
could  occur-  [Ref.  28]  The  common  denominator  selected  for 
the  measures  is  monetary  value,  and  a  year  is  the  time 
period  against  which  frequencies  of  occurrence  will  be 
assessed.      To  simplify  such    quantitative   measures,    estimates 
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for  impact  and  frequency  are  rounded  off  to  factors  of  --n. 
The  range  cf  measures  for  both  caiiegories  is  shown  in  Tacle 
IV. 


TABLE    IV 
Orders   of  Hagnitude  of  Estimated   Impact   and  Frequency 

IMPACT; 

510 

$100 

$1000 

$10,000 

$100,000 

$1,000,000 

$10,000,000 

$  100,000,000 

FREQUENCY: 

Once  in    300   years 

Once  in    30    years 

Once  in 

Once  in 

Once  in 

One 


3    years    {1000    days) 
100    ^ 


days 
10    da  y  s 

per    iay 
10    times   per   dav 
100   times   per    day 


The  FIES  emphasizes  that  roundrng  off  the  figures  will 
not  have  a  significant  effect  on  the  overall  ALE.  The  rele- 
vance lies  in  orders  of  magnitude  rather  than  in  absolute 
figures.  Thus,  "there  will  be  nc  significant  difference  in 
the    overall    exposure    whexher   the    damage    from    a   certain    event 

is      estimated        at      1110,000      or        $145,000 (or) if      the 

frequency   of  an    event   is    expected      to    be   twelve    times    a   year 
cr      thirty"      [  Ref-    29]-  Once      the      impact      and      frequency 

measures    have   besn    determined,    the  ALE    can    be   readily   calcu- 
lated  using    the    following  formula   : 
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LOSS    =    IMPACT  (I)     X    FREQUENCY    OF    OCCnRRENCE    (F) 

To  use  this  formula,  however,  it  Is  first  necessary  to 
index  the  impact  (i)  and  the  frequency  (f)  measures  from 
Table   IV.      The    resulting   indices    are    shown   in   Table    V, 


TABLE  7 

Table  for  Selecting  of  Values  of  i  and  f 

If  the  estimated  cost  impact  of  the  event  is 

$10,  let  1  =  1 

$100,  let  i  =  2 

$1000,  let  1  =  3 

$10,000,  let  1  =  4 

$100,000,  let  1=5 

$1,000,000,  let  1=6 

$10,000,000,  let  1=7 

$1 00,000,000,  let  1=8 

If  the  estimated  frequency  of  occurrence  is 

Once  in  300  years,   let  f  =  1 
Onca  in  30  years,    let  f  =  2 
Once  in  3  years,     let  f  =  3 
Once  in  100  days,    let  f  =  4 
Once  Id  10  days,     let  f  =  5 

Once  per  day,       let  f  =  6 
10  times  per  day,    let  f  =  7 

100  times  per  day,   let  f  =  8 

1 1 

To    use    the    indices    in  the   previous   equation,  they    must    firs- 

be    related    to      Impact    (I)       and    Frequency      of  Occurrence    (F)  , 

Such      relationships      are    expressed        in    the  following    equa- 
tions   : 

i 

for    Impact,         I   =    10 

(f-5)         f 
for  Frequency,   F   =  10      /3   =  10   /3000 
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Thus,    if    the    impact  of  an    event  is    esrimatad    at    $100    (i=2 

i        .  -2 


from    Table    V)    then    I    =   10      =10      =    100.         Similarly, 


:n9 


frequency      of   occurrence      is   estimated     to    be      once    psr      day 
(f=6)  ,    then    F   =    10    /3000    =     10    /3000    =    333.3. 


Consider  the  following  practical  3xampl9,  where  the 
potential  impact  of  a  hurricane  is  $100,000  in  damage  to  a 
computer  facility,  and  the  frequency  for  a  hurricane  is  once 
in   thirty   years.    The    ALE  would   then   be  compuusd   as    fellows   : 

IMPACT    :         5100,000    (i=5) 

I    =    10      =   100,000 

FREQUENCY   :       1/30    years       (f=2) 

2 

F    =    1C    /3000    =    .0333 

LOSS:         I  X    F    =    100,000    x    .0333   =    3,330 


Thus,  the  ALE  resulting  from  a  hurricane  would  be  approx- 
imarsly    13,000- 

It  is  no+  necessary,  howvever,  zc  compute  the  ALE  using 
these      tedious      and      cumoersome    equations.  The      FI?S      FUB 

provides  figure  2.2  to  facilitate  the  process.  The  ALE  for 
a  particular  event  can  then  be  found  at  the  intersection  of 
the    values   estimated    for   impact   and    frequency. 

When  all  ALEs  have  been  calculated,  the  FTPS  PUB  suggests 
that  the  approach  to  the  remainder  of  the  task  be  done  in  an 
orderly  and  structured  manner.  In  short,  it  recommends  that 
"...the  risk  analysis  task  is  better  approached  from  the 
standpoint  of  the  data  files,  or  applications  systems,  of 
which    there    is    a   finite   number"   [Haf.    30]. 
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1 — 

1 

1 
1 

Once  in  300  yrs 

(100.000  days)           | 

Once  in  30  yrs 
(10.000  days) 

Once  in  Syrs 
(1.000  days) 

Once  in  100  days 
Once  in  10  days 
Once  per  day 
10  per  day 
100  per  day 

■  ■■   — 1 

$10 

$100 

$1000 

$10,000 

$100,000 

$1,000,000 

$10,000,000 

$100,000,000 

^ 

1 

2 

3 

4 

3 

6 

7 

8 

1 

$300 

$3,000 

$300k 

2 

$300 

$3,000 

$30k 

$300k 

$3M 

3 

$300 

$3,000 

$30k 

$300k 

$3M 

$30M 

4 

$300 

$3,000 

$30k 

$300k 

$3M 

$30M 

3 

$300 

$3,000 

$30k 

$300k 

$3M 

$30M 

$300M 

6 

$3,000 

$30k 

$300k 

$3M 

$30M 

$300M 

7 

$30k 

$300k 

$3M 

$30M 

$300M 

8 

$300k 

$3M 

$30M 

$300M 

J 

Figure  2.2        Ccmbinad   Matrix   of   i,    t,    and    ALE. 

In  terms  of  such  software  considerazions,  -hs  publication 
discusses  thre^  conditions  which  might  result  if  a  threat  to 
a      computer    system      were   realized      :  DATA    INTEGRITY      (eg. 

destruction  or  unauthorized  modifications  to  data);  DATA 
CONFIDENIIALITY  (ie.  a  compromise  of  classified  data) ;  and 
ADP  AVAIIAEILITY  (pertaining  to  the  amount  of  time  that  a 
computer    system    can    te   returned   to  service    after    failure) . 

To  provide  structure  and  order  to  the  recording  of  the 
risk  assessment  findings,  the  ?IPS  PUB  supplies  the  work- 
sheet presented  as  figure  2.  3  Such  a  worksheet  might 
simplify  the  record-keeping  aspect  of  the  process,  but  it  is 
only  a  suggestion  -  if  used,  it  should  be  formatted  or 
tailored   tc   an    agency's   needs. 
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On  this  particular  worksheet,  data  files  ara  listed  sepa- 
rately, and  arranged  by  application.  Impac-  and  frequency 
estimates  and  ALZ(s)  for  each  category  of  -hr-^at  are  then 
listed  alongside  the  associated  file.  A  ccmmen-s  column  is 
provided  to  allow  for  an  amplification  of  the  figures  shown. 
As  an  additional  guide  to  using  these  work  sheets,  the  FIPS 
FOB  presents  a  practical  example  (for  a  small  organizaticn) 
of   a    complete  risk    assessment. 

The  fliS  PUB  attempt  to  structure  the  risk  assessment 
process  adds  a  degree  of  credibility  to  the  overall  methcd- 
ology.  Hcwever,  it  is  unreasonable  to  expect  that  the  whole 
process  can  be  carried  out  as  a  "cookbook"  method.  There 
are  definite  limits  *c  structuring  such  a  task,  particularly 
in  areas  such  as  identifying  and  estimating  the  threats 
against  a  facility.  In  short,  "ADP  risk  analysis  is  a  tech- 
nique which  reliss  heavily  en  the  intuition,  experience  and 
technical   knowledge    cf   the    team   members"   [Ref-    30]. 

H.       COHHENT    DIRECTIVES 

Approximately  a  year  after  the  release  of  FIPS  PUE  65, 
the  NES  distributed  a  ten-page  document  entitled  "Risk 
Analysis  Standard".  The  purpose  of  this  document  was  simply 
to  standardize  the  terminology  and  concepts  behind  the  DOD 
philosophy      for    conducting      risk    assessments.  It    did      not 

supply   any    specific    guidelines   or   methodologies. 

Finally,  in  August,  19  82,  the  DON  approvf^d  and  distri- 
buted OEiJAVINST  5239. 1A,  a  full  and  comprehensive  manual 
describing  the  Navy's  AD?  Security  program.  A  significan-^ 
portion  cf  this  manual  addresses  the  approved  OCN  risk 
assessment  lethodolcgy,  complete  with  forms  and  specific 
directions.  The  procedural  aspects  of  this  methodology  will 
be    presented  as    a   practical      framework   for   a    risk    assessment 
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that    cculd      be    ccLduct^d    at      *he    Naval      Postgraduate    School. 
in   Chapter    4. 

This  chapter  has  described  how  the  carr ently-approved  DON 
nethodoloay  has  evolved  over  the  years.  Figure  2.U  shews  a 
time  line  cf  the  events  leading  ap  to  the  distribution  of 
CPNAVINST    5239.  1  A. 
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III.    IN-HOOSE    VS    CONTEACTOAL    SUPPORT 


A.       GENEfiAI 

With  the  distribution  of  03B  Circular  A-7 1  in  1978  came 
the  reguiiement  that  a  "Risk  Assessment"  (some-imes  refarrad 
to  as  a  "Risk.  Analysis")  be  conducted  at  each  computer 
installation  operated  by  a  federal  agency.  Whila  the  risk 
assessment  loethcdolcgy  currently  recognized  within  the 
Department  of  Defense  is  a  manual  syst3m,  there  are  commer- 
cial software  packages  available,  notably  PANAUDIT  by 
Pansophic  Systems,  which  could  facilitate  the  "number- 
crunching"  aspect  of  risk  assessments.  Unfortunately,  this 
particular  software  is  only  IBM-compatible,  and  thus  has 
limited    application    tc  Navy    computer    systems. 

In  the  past  few  years,  numerous  government  directivas  and 
guideliTiSS  en  me  thodclcgies  for  conducting  risk  assessments 
have  teen  disseminated.  liany  of  these  have  resulted  frcm  a 
joint  effort  on  the  part  of  government  and  commercial 
industry.  In  1977,  in  an  effort  to  perfect  a  mere  concise 
methcdolcgy  that  could  be  applied  to  various  sizes  and  types 
of  computer  systems  within  the  Department  of  the  Navy, 
COMNAVDAC  let  a  contract  wita  Systems  Development 
Corporation  (SDC)  to  divelop  and  document  such  a  methcd- 
clogy.  This        contract,         involving        contractor      support 

services,      falls      under   the      Policy/Program    Review      category 
outlined      in   NAVMATINST      4200. 50C.  The    justification      for 

contracting    cut    such      a    service   was    undoubtedly      a    matter   of 
the      expertise    held      by      the      commercial    marketplace.  The 
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result  of  the  contract  with  SDC  is  containsd  in  NAVDACINST 
5510.1,  the  Department  of  tha  Navy  ADP  Security  Manual. 
While  still  in  draft  form,  the  distribution  of  this  manual 
will  serve  as  an  excellent  reference  for  those  Naval  agan- 
cies    about   to   initiate  a    risk   assessmant. 

''  •      lh~.    Ne^l  L2I.   Contractual    Support 

Many  gcvernnient  directives  pertaining  to  ADP 
Security  provide  guidance  on  tha  in-house  personnel  an 
agency  !!iust  use  to  form  their  risk  assessmant  team.  Such 
personnel  generally  include  representatives  from  ADP 
Operations  Management,  Systems  and  Applications  Programming, 
Hardware  Maintenance,  Communications  Sngjineeriiig ,  Internal 
Auditing,  and  the  Security  Staff.  Since  a  comprehensive 
risk  assessment  is  a  time-consuming  process,  diverting  the 
services  of  these  individuals  from  their  normal  iuties  could 
well  create  a  hardship  within  their  divisions  or  dapart- 
nients.  This  potential  hardship  was  recognized  by  personnel 
at  NAVCAC  who  began  to  consider  the  possibilities  of 
allowing  for  contractual  support  in  conducting  risk  assass- 
mants.  Although      previous        directives      only        discussed 

conducting  risk  assessments  in  terms  of  using  in-house 
personnel  resources,  NAVDACINST  5510.1  mentions  that  quali- 
fied ccrtractors  may  ba  used  with  prior  approval  from 
NAVDAC. 

2  •      1    £  r  ot  0 1  yp  e    for    a  Contracted    Risk    Ass  ess me nt 

In  early  1980,  personnel  at  the  Fleet  Numerical 
Oceanography  Center  (fNOC)  in  Monterey,  California,  began  to 
have  serious  doubts  about  their  ability  to  conduct  an 
in-hcusa  risk  assessment.  Tha  computer  configuration  at 
FNOC,  consisting  of  cumerous  large-scale  mainframes,  ccmmu- 
nicaticns  networks  and  devices,  minicomputers,  and  peri- 
pherals,   was  extremely   large   and   complex.         It   would    be    very 
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difficulT  to  spare  the  key  parsonnel  needed  on  th~  risk 
assessment  team  from  their  everyday  d'aties.  Witn  this  ir. 
mind,  the  ADP  Security  Officer  ar  FNOC  wrote  -o  NAVDAC 
asking  fcr  guidance  en  using  contractor  assistance.  NAVDAC, 
which  had  teen  giving  this  issue  a  great  deal  of  thougnt, 
decided  to  use  FNOC  as  a  prototype  for  future  contracted 
risk    assessient    efforts.  To   this   end,      NAVDAC      offered   to 

lend  technical  assistance,  provide  liaison  with  the 
contractor  and  other  knowledgable  government  agencies,  and 
oversee  the  entire  process.  The  government  agencies  to  be 
involved  (directly  or  indirectly)  m  the  process  are  these 
shown  in  figure  3.1,  which  was  extracted  from  NAVDACI:1ST 
5510.  IX   [Ref-    33].  These    agencies    roughly      parallel    these 

which  play  a  key  role  in  faderai  acquisition  policies  and 
procedures. 

3  .      Standar  diza,t  ion    in    Contracted   3 isk    Assessments 

While  the  end  result  of  this  contract  effort  was  to 
te  a  ccmcleted  risk  assessment,  it  rfas  also  serving  as  a 
standard  against  which  future  risk  assessments  could  be 
conducted.  Thus,  as  concerns  arose  during  the  project, 
NAVDAC  documented  them  and  considered  ways  in  which  the 
process  cculd  be  enhanced  and  standardized.  This  study  will 
briBfly  summarize  the  events  that  occurred  during  FNOC's 
risk  assessment,  shew  how  NAVDAC  monitored  and  ccntrclled 
the  whcle  process,  and  describe  how  NAVDAC  has  streamlined 
the  system  to  facilitate  contractor  support  on  any  activi- 
ty's   risk   assessment. 

4 .      Ereliminarv    Efforts 

NAVEAC's  first  pricrity  in  assisting  FNOC  was  to 
gather  a  pool  of  personnel  whose  technical  expertise  would 
facilitate  the  project.  To  this  end,  FNOC  was  provided  a 
copy      of      NAVDACINST    5230. 1  A,        "Procedures      for      Requesxing 
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Figure  3.1   DON/&DP  security  Organizational  Relationships. 

Services  frcm  Navy  Regional  Data  Automation  Centers 
(NARBACs)".  FNOC*  3  task:  va  s  -^o  generate  a  letter  reguesring 
technical  support  services  from  NA3DAC,  San  Francisco. 
Included   in  this   letter   was   information   pertaining  to 
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project  title,  requesting  ccramand,  type  of  request,  objec- 
tives, security  classification,  and  funding.  Identifying 
the  source  of  the  funding  is  an  important  consideraxion  m 
requesting  NARDAC  services.  "Commencing  in  fiscal  year  1982 
all  Navy  cusromers  of  a  NAHEAC,  except  Navy  industrial  Fund 
Activities,  will  be  supported  on  an  entirely  mission  funded 
basis ... Dnprcgrammed  costs  which  cannot  be  accommodated  will 
be  subject  of  discussion  between  the  NARDAC  and  the  customer 
to  determine  if  other  means  of  funding  are  available" 
[Ref.  34].  In  this  situation,  FNOC  had  budgeted  $100K  for 
the  risk  assessment  project,  and  the  NARDAC  had  no  funds 
available.  It  was  thus  determined  that  FNOC  would  remit  the 
$100K  to  the  NARDAC,  who  along  with  NAVDAC,  would  use  the 
funds  to  cover  the  costs  of  the  government* s  technical 
suppcrt   personnel   and  the  contractor's   fees. 

Once  the  method  of  funding  had  been  determined, 
NAVDAC  sent  technical  experts  from  the  NARDAC,  NAVELZX,  and 
NESEA  (Naval  Electronics  Systems  Engineering  Activity)  to 
FNOC  to  discuss  the  program  with  ADP  Security  personnel. 
These  personnel  outlined  the  project  and  generated  a  docu- 
ment on  FNCC* s  computer  assets  for  use  by  the  ccrtractcr. 
NAVCAC,  in  the  meantime,  was  using  inputs  from  this  group  to 
generate  a  plan  of  action  and  milestones  that  the  contractor 
would    be    expected    to    follow. 

5-      The    Contract 

NAVEAC  handled  all  the  requirements  for  negotiating 
and  awarding  the  contract.  The  details,  however,  on  the 
negotiaticns,  evaluation,  selection,  and  award  were  not 
available  to  the  authors.  After  the  negotiations  had  been 
completed,  the  contract  was  awarded  to  Systems  Development 
Corporation    (SDC). 
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Ey  tha  time  the  SDC  personnel  arrived  at  FNOC,  they 
had  been  in  constant  touch  wirh  zhe  project  manger  at 
NAVDAC,  and  were  well  aware  of  ^he  tasks  expec-ed  of  them. 
By  interviewing  personnel  from  all  areas  of  FNOC's  organiza- 
tional components,  reviewing  computer  ccnf igura-icn  sche- 
matics and  documentation,  penetrating  computer  security 
vuln  arabilities  and  merging  them  v/ith  potential  threats, 
they  were  able  to  assess  FNOC's  security  posture  and  produce 
the  required  documentation  and  Annual  Loss  Expsctancy  (ALE) 
figures. 

6.      Future    Risk    flssessm  ent   Contracts 

Since  a  risk  assessment  contract  will  call  for  a 
study  or  analysis  of  the  security  aspects  of  an  existing 
computer  system,  it  will  have  to  adhere  to  the  requirements 
of  NAVMAIINST  4  200. 50C  which  addresses  contractor  support 
services.  If  FNOC's  contract  was  any  indication,  future 
risk  assessment  contracts  will  undoubtedly  exceed  $50k,  and 
thus  will  require  legal  reviaw  and  approval  by  "...a  level 
no  lower  than  Flag  or  General  Officer  or  individuals  in  the 
Senior   Executive   Service    (SES)"   [Ref.    31]. 

In  an  effort  to  make  FNOC  and  its  parent  command. 
Commander,  Naval  Oceanography  Command  (CNOC) ,  more  autono- 
mous in  contracting  for  future  ADP  security -re la  ted 
services,  KAVDAC  recently  drafted  a  letter  in  which  the 
subject  line  r=ads,  "Automated  Data  Processing  (ADP) 
Security      Accreditation   and      Contractor    Assistance".  This 

document  will  be  invaluable  to  any  Naval  activity  consid- 
ering contract  support  in  complating  a  r:.sk  assessment. 
Although  the  information  will  not  br  afforded  general 
distribution,  NAVDflC  is  amenable  to  providing  it  when 
requested  by  a  Navy  activity.  The  several  enclosures  to  the 
document    constitute      sample    ADP      security    contracting      docu- 
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ments,  which  as  NriVDAC  mentions,  masx  be  tailored  *o 
specific  tasking  requirsments  and  coordinated  with  the  local 
Navy  Eegicnal  Contracting  Center.  NA7D^C's  purpose  m  -his 
effort  is  "...an  attempt  to  assure  that  Navy  activi-ies 
receive  quality  contractor  ADP  security  reports  and  products 
for    dollars   invested"  [Bef-    32]. 

Affong  the  enclosures  is  a  sample  statement  of  work 
which  may  be  tailored  and  included  as  part  of  an  activity's 
Bequest  for  Proposal  (RF?)  ,  or  in  NAVDAC  terms.  Task  Order 
or  Task  Bequest,  The  sample  not  only  addresses  risk  assess- 
ments, tut  ciloo  includes  other  ADP  security  areas  wnich  may 
be  candidates  for  contractor  assistance  :  Risk  Assessment 
Planning,  Contingency  Plan  Testing,  and  Security  Training. 
It  is  the  jcb  of  an  activity's  ADP  Security  Officer  to  write 
a  task  request  based  on  the  statement  of  work,  describing 
the   specific     ar=a    of  the      work   required.  NAVDAC's   sample 

work  statement  has  specific  guideli^nes  on  the  necessary 
wording,  including  a  list  of  military  publications  to  which 
the  contractor  must  be  responsive,  and  a  list  of  required 
deliverables  such  as  summary  progress  reports,  schedule  of 
performance,  and  contract  financial  progress  reports.  The 
sample  work  statement  also  includes  an  option  to  extend  the 
term  of  the  statement  of  work.  This  will  be  renewable  at 
prices  stated  by  the  contractor  and  at  the  option  cf  the 
government.  In  addition,  NAVDAC  provides  guidance  on  the 
Gcverr.mert-Furnished  Equipment  and  documentation  tha-^  an 
activity  should  be  prepared  to  picviie  the  contractor. 
Other  documents  NAVCAC  has  included  as  samples  are  :  the 
Contract  Security  Classification  Specification,  detailing 
the  security  considerations  and  access  requirements; 
Contractor  Personnel  Qualifications  Statement,  describing 
the  minimum  qualifications  expected  of  the  contractor 
personnel   assigned    tc   the      project;       Personal   vs    Nonpersonal 
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Services  Questionnaire,  a  document  used  by  the  cont;racri-g 
officer  zo  determine  whether  or  net  the  solicited  service  is 
nonpersonal;  and  the  Contract  Data  Requirements  Lis*,  which 
describes  the  required  deliverables.  Thise  are  all  standard 
requirements  for  an  RFP,  but  rhey  have  been  uniquely 
tailored    for  a    Risk    Assessment    application. 

As  cf  28  July  1982,  NAVDAC  had  approved  six  organi- 
zations to  he  included  on  the  Bidder's  idailing  List.  These 
organizations  and  their  qualifications  are  shown  in  figure 
3.2.  At  the  time  of  this  writing,  three  were  qualified  to 
conduct  risk  assessments,  but  only  two  of  these  had  DON 
approval.  Two  of  the  organizations  listed  were  small  busi- 
nesses. 

Each  of  these  vendors  will  be  notified  of  a  task 
request  by  the  Contract  Administration  Office  (CAO)  . 
Vendors  are  required  to  pick  up  the  task  request  within  a 
week  cf  notification.  NAVDAC  refers  to  vendor  responses  as 
"Task  Order  Proposals"  (TOPs).  As  is  the  case  with  standard 
EFPs,    these    are    due    at  a    specified  time    and   date. 
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7.      Eicposal   Evaluations   and   Selection 

Infcrmation  required  in  a  TOP  for  a  risk  asssssmen^ 
includas  "the  number  of  man-hours  by  skill  cat<=gory  by  task 
and  sufctask,  milestone  dates,  xravel  costs,  proposed  pricing 
arrangements,  personnel  resumes,  and  -schnical  approach" 
[Ref.  32].  The  function  of  the  activity's  technical  evalua- 
tion hoard,  chaired  by  the  ADP  Security  Officer,  who  is 
generally  assigned  as  project  manager,  will  be  to  evaluate 
these   factors. 

NAVEAC  stresses  the  impor-cance  of  ccntracxor 
personnel  qualifications  in  evaluating  and  selecting  the 
contractor.  Particular  emphasis     is      placed  on      personnel 

weighting  factors,  with  the  result  ^hat  factors  onher  than 
cost  may  weigh  heavily  in  the  selection  of  one  contractor 
over    another.  The   list      of   qualifications      for   contractor 

personnel  are  quite  comprehensive.  Particularly  important, 
especially  for  the  lead  person  assigned  by  the  contractor, 
is  experience  in  computer  center  operations,  ADP  Bisk 
Assessment  methods,  system  software  generation,  computer 
security,  telecommunications  security,  and  computer  hardware 
and  interccnnections.  A  proposal  which  describes  personnel 
with  less  than  these  qualifications  may  be  considered  "non- 
responsive".  In  order  to  promote  continuity  and  stability 
throughout  the  length  of  the  project,  NAVDAC  also  encourages 
considering  the  contractor's  response  to  the  requirement 
that  "50  percent  of  original  contractor  personnel  arriving 
on  a  Navy  site  to  perform  a  risk  assessment  will  remain  on 
site    for   the  duration  of   the   contract"   [fief.    32]. 

Evaluation  of  cost  factors  will  generally  be  handled 
by  the  Procuring  Contracting  Officer  of  the  Navy  Regional 
Contracting  Center.  This  will  exclude  consideration  of  the 
cost    of      preparing    the      TOP,      which,         as    is      the    cass      with 
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conveEt icnal  RFPs,  is  done  at  -he  expanse  of  zae  ccnTract or . 
Howaver,  those  prices  which  will  b=  recognized  include  "all 
direct  labor,  overhead,  general  and  ada^nistr ative  expenses, 
plus  an  amount  for  profit"  [Hef-  32].  In  this  regard,  mosT: 
risk  assessment  contracts  will  probably  be  of  the 
Cost-plus-fixed- fee      type.  Based      on        NAVDAC's      general 

guidance  for  evaluation  factors  and  weightings,  a  proposed 
Internal  Score  Sheet  for  any  activity's  TOP  evaluation  is 
included  as  figure  3.3  .  The  reasoning  for  the  discrepancy 
between  experience  and  past  performance  is  as  follows  : 
experience  in  all  areas  listed  is  crucial,  and  while  past 
performance  on  related  contracts  would  certainly  be  a 
desired  feature  in  a  contractor,  chances  are  that  few  will 
have  dealt  directly  with  risk  assessments  (considering  that 
they  are  a  relatively  new  requirera€»nt)  .  Price  factors 
should  ccnstitut?  about  20  percent  of  the  total  weighting. 
After  the  contract  administrator  has  completed  the  negotia- 
tions, the  selection  is  made,  and  "a  finalized  Task  Order 
will  be  executed  by  the  contractor  and  the  contracting 
officer"   [Ref.    32]. 

B.       CCNCIDSIONS 

NAVEAC's  recognition  of  the  need  for  allowing  contractor 
assistance  in  conducting  computer  risk  a3ses3aen*-s  is  both 
admirable   and  realistic.  Even    if    an   activity      could    spare 

the  personnel  necessary  to  conduct  a  risk  assessment,  there 
would  undoubtedly  be  a  lack  of  expertise  in  the  necessary 
policies  and  procedures.  At  this  stage  of  the  game,  where  a 
risk  assessment  is  still  a  relatively  new  and  complex  pheno- 
menon, few  people  understand  what  it  is,  let  alone  hew  to 
conduct      an      assessment.  (This      will      undoubtedly      change, 

however,  as  NAVDAC  places  more  and  more  emphasis  on  ADP 
Security    training)  . 
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Internal  Score  Sheet 


1.  Technical    Approach   --   weight   30    pcints 
a.)     Understanding   of    Task 

1.)    Bisl(    Assrssn?nt 
2.)    flathcdoiogy 
b.)     Hespansivan^ss   to   specifications 

in    Task   Request 
c.)     Appropriateness   of   approach 
1.)    Activity's   ecvironien t/ops 
2.)    Activity's   coiputer    configuration 
3.)    DON-approved   risk  isssssaent 
requireaents 

2.  Experience     —      weiqht    30    points 
A.)    Coaputer  canter   Operations 
B.)     ADP   aisk   Assessment    flarhods 
C.)     Systa*    Software   Generatioa 
D.)    Coapatar  Security 

S.)    Telecoaaanications   Security 
P.)     Coaputer  Hardware   and  Interconnections 
S.)    Clearance   coaaeasurate    with    the   highest 
level  contained    in    the   systpa 

3.  Past    Perforaanca    —    weight    15   points 

A.)      Conducting   Risk      Assessaents 

B.)    Parforaing    ADP    Sacurity-ralated   projects 

1.    Uanaqeaent    —  weight    20    points 


0-4 
0-4 

0-15 

0-3 
0-2 

0-2 
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5.    Location    —    weight   5    points 

(with   the   understanding      that    50%   of    the      original   contractor 
personnel   raaain    on   site    for    the   duration    of    tha    contract). 


OFFEROB    : 
ETALOATOB 


Figure  3.3        Contractor   Evaluation   Score  Sheet- 
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While  specific  details  and  samples  of  ccntracr  dccumezts 
are  available  to  any  activity  requesxing  them,  NAVCAC 
encourages  tailoring  them  to  the  activity's  needs.  As  top 
management,  security  personnel,  and  computer  specialists 
become  mere  educated  in  the  risk  assessment  phencmencn,  the 
need  for  such  specific  guidance  will  dwindle.  In  the  mean- 
time, gcvernment  resources  will  be  saved  by  avoidu.ng  the 
possibility  of  mismanagement  cf  contracting  for  computer 
risk    assessments. 
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IV.     A    FBAjJEWORK   FOE    CONDUCTING    A    RISK    ASSESSMENT    AT    NPGS 

Th€  repartmsnt  of  rhe  Navy  Automatic  Data  Processing 
Security  Program  was  rscently  promulgated  by 

CPNAVINST.5239. 1 A  on  August  3,  1982.  The  instruction 
provides  policy  and  guidance  to  commanding  officers 
concerning  the  establishment  of  local  auxomatic  data 
processing  (ADP)  security  programs.  Each  command's  program 
should  be  designed  with  the  goal  of  achieving  accreditation 
by  the  appropriate  designated  approving  authority  (DAA)  .  In 
particular,  each  activity  must  develop  an  activity  ADP 
security  plan  (AADPSP).  This  plan  must  be  approved  by  the 
Commander,  Naval  Data  Automation  Command  (COMNAVDAC) .  The 
AADPSP  should  document  current  security  environment,  estab- 
lish program  objectives,  and  outlina  a  plan  of  action  and 
milestones  (POAM)  for  security  program  implementation.  An 
item  that  will  be  included  in  the  POAM  is  the  completion  of 
a  risk  assessmerat.  A  risk  assessment  may  be  conducted  inter- 
nally if  an  ADP  activity  has  the  necessary  axpertise 
Commercial  assistance  is  available  to  conduct  a  risk  assess- 
ment, CCMNAVDAC  maintains  a  list  of  authorized  contractors 
and   retains    approval   authority    for  contractor   selection. 

This  chapter  provides  a  framework  for  conducting  a  risk 
assessment  at  the  Naval  Postgraduate  School.  A  framework,  in 
the  absence  of  theory,  is  helpful  in  organizing  a  complex 
subject,  identifying  the  relationships  between  the  parts  and 
revealing  the  areas  in  which  further  development  may  be 
required  £Hef.  35]*  A  risk  assessment  at  a  naval  activity 
must  be  governed,  of  course,  by  OPNAVINST.  5239.1  A.  However, 
this  instruction  is  very  broad  in  scope  and  covers  the 
entire  ADP  security  spectrum.  It  should  be  helpful  to  have 
the  necessary  steps  fcr  a  risk  assessment  ,  applied  to  the 
Naval   Postgraduate   School,    presented    in   this    framework. 
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A  risk  assessment  invclvas  a  detailed  examination  cf  all 
the  aspects  cf  a  computer  system:  hardware,  software,  data, 
procedures,  etc.  The  use  of  these  assets,  that  is,  -hs  use 
of  the  ccmputer  systems  at  the  Naval  Postgraduate  School, 
including  the  IBM  3033AP  system  in  the  irf.C.  Church  Computer 
Canter,  various  mini  and  microcomputers  in  Spanagel  Hall, 
and  independent  units  obtained  under  grant  by  several  prof- 
essors, spans  virtually  all  departments  and  includes 
faculty,  students,  and  military  and  civilian  staff.  This 
fact  implies  that  a  significant  amount  of  cooperation 
between  different  organizations  will  ba  reguired  to  success- 
fully ccirplete  a  risk  assessment.  This  endeavor  requires 
command  attention  at  upper  levels  to  impress  upon  all 
concerned  the  importance  with  which  the  command  views  a 
subject  cf  this  nature.  With  this  understanding,  a  project 
cf  this  magnitude  should  produce  meaningful  results  which 
will    serve    several    purposes; 

1)  Enable    the    Naval    Postgraduate   School   to    proceed 
successfully    along    the   path    to   AD?    security 
accreditation. 

2)  Provide    documentation    sta-cing    the    current    condition 
of   security    with   respect    to    the   computer   sysxams 

at   the    Naval    Postgraduate   School. 

3)  Provide    a  reference    for   quantitatively  evaluating 
security  countermea sures. 

U)     Provide    a  platform    from    wnich    improvements    in 
command    security    posture    can    be    built. 

A-       INITIAL    STEPS:     PERSONNEL    SELECTION    AND    SECURITY    SURVEY 

The  initial  step  in  undertaking  this  project,  is  to  iden- 
tify the  personnel  who  will  participate  as  members  of  the 
risk  assessment  team.  Expertise  from  various  disciplines 
such    as      computer   science,       management,         and  administrative 
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sciance  will  be  required.  Personnel  selection  is  a  vary 
delicate  subject  in  the  commercial  environment.  Donn  Parker 
of  the  Stanford  Research  Ins-citute  (SRI),  at  the  1977 
National  Computer  Conference,  criticized  the  concep-  of  a 
risk  assessment  team  made  up  of  key  company  personnel.  A 
team  approach  gives  a  relatively  large  number  of  einployees  a 
virtual  inventory  of  data  processing  vulnerabilities.  It 
may  be  prudent  to  have  risk  assessment  team  members  partici- 
pate in  detailed  analyses  only  on  a  need-to-kncw  basis. 
[Ref.  40]  Hcwever,  this  situation  will  not  pose  a  problem  at 
the  Naval  Postgraduate  School.  Given  the  relatively  tran- 
sient nature  of  students  and  staff  at  this  institution,  the 
following  recommendations  for  staffing  this  project  are 
proposed.  The  position  of  project  manager  should  be 
assigned  to  the  ADP  security  officer.  The  tasks  which  this 
position  entails  are  quite  consistent  with  the  duties  of  the 
ADP  security  officer.  Additionally,  the  participation  of 
studenxs  from  the  Computer  Systems  Management  and  the 
Computer  Sciencs  curricula  should  be  solicited.  The 
majority  of  the  work  required  in  this  project  could  be 
completed  by  students.  The  risk  assessment,  may  serve  as  a 
Thesis  project  for  several  teams  of  interested  students. 
Faculty  members  of  the  Computer  Council  could  function  in 
the  role  of  thesis  advisors  while  maintaining  an  active 
interest  in  the  risk  assessment  process.  The  project  could 
be  broken  into  three  distinct  phases.  Students  partici- 
pating in  these  phases  would  build  directly  upon  the  work 
accomplished  by  earlier  students.  A  proposed  phased  organi- 
zation might  be: 

1)  Security  Survey,  Asset  Identification  and  Valuation 
Phase 

2)  Threat  and  Vulnerability  Evaluation  Phase 

3)  Computation  cf  Annual  Loss  Expectancy  and  Evaluation 
and  Selection  of  Additional  Countermeasures  Phase 
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Ths  formal  assignment  of  personnel  to  the  Risk 
Assessment  Team  is  accomplished  by  the  issuance  of  the  Risk 
Assessment   Team    Charter.  The   charter    is    generated      by   -he 

command  itself  and  identifies  -chose  personnel  who  compose 
the   team.  Since    studenrs      will   be      participating   in      this 

endeavor,  periodic  updates  to  this  docum^ni  will  be 
required.  The  document:  lists  the  objeciives  of  the  team  and 
details  the  authority  and  responsibility  of  each  person. 
The  charter  also  states  the  products  which  the  team  is 
expected    to   produce. 

The  next  step  in  the  overall  process  is  to  conduct  an 
ADP  security  survey.  A  sample  survey  is  listed  in  the  ADP 
Security  manual  [Ref.  36].  An  item  which  will  be  needed  to 
ensure  that  the  survey  is  complete  is  a  listing  of  all  ADP 
equipaent  located  at  the  Naval  Postgraduate  School.  The 
survey  should  encompass  all  equipment  so  that  its  results 
can    be      interpreted    with      seme    degree      of    confidence.  The 

results  provide  an  indication  of  the  current  security  situa- 
tion and  also  may  shew  how  much  effort  will  be  required  to 
conduct    the     risk   assessment.  It    should      be   noted      that   a 

complete  and  accurate  listing  of  all  equipment  is  crucial  to 
the  success  of  the  overall  assessment.  Failure  to  include 
certain  equipment  may  invalidate  any  assessments  made  on 
ether  equipment  affected  by  missing  items.  The  major  compo- 
nents of  the  IBK  3033A?  system  are  listed  in  an  NPGS  pabli- 
cation,  "Introducticn  to  the  Church  Computer  Center".  Of 
course,  this  information  should  be  verified  prior  to  use  in 
this    endeavor. 

The  vast  majority  of  the  users  are  not  working  with 
high-value  data,  but  rather  with  routine,  academically 
oriented    material.  No   classified    data      is    supposed      to   be 

stored  on  the  IBM  3033AP  system.  Additionally,  most  of  the 
processing  done  at  the  Church  Computer  Center  is  not  in 
support   of      fleet  operations.  The    results     of    the      survey 
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indicate  some  directicns  for  the  risk  assessiisnt  to  oursu^. 
The  formal  resulxs  of  the  survey  should  be  compiled  and 
submitrsd   as  an    apper.dix    to    t.he   risk    assessmenr    dccumer.t. 

The  results  of  the  survey  also  impact  upor.  the  risk 
methodology    selected.  As    the    kDP    Security      manual   states, 

"the  decisicn  (ccncsiring  which  methodology  to  use)  should 
be  based  on  rhe  complexity  of  -che  ADP  environment.  The 
complexity  is  governed  by  the  level  of  da-a  processed, 
security  mode  of  operation,  ADP  sys-em  configuration  and 
location,  and  the  criticality  of  rhe  mission."  [Ref.  37] 
There      are   two       methcdologies    available.  The    most      common 

methcdclcgy  for  ADP  activities  is  listed  in  the  Security 
manual   as      Methodolgy    1.  This    methodology      appears   to      be 

suitable  for  a  risk  assessment  at  the  Naval  Postgraduate 
School.  Methodology  1  is  the  standard  methodology  us€d  in 
most  ADP  environments  and  provides  for  suitable  inreraciion 
between    threats    and    losses.  The   risk    assessment    conducted 

according  to  methodclogy  1  can  be  divided  into  several 
phases  as  shown  in  figure  4.1.  As  previously  mentioned, 
these  phases  could  quite  conveniently  be  assigned  to 
students    as    thesis    prcjec-s.  The    successful  completion   of 

each  phase  is  well  within  the  capabilJL-ies  of  interested 
students . 

B.        ASSET    IDENTIFICATION    AND    VALOATION 

The  next  phase  in  this  process  consists  of  asse-  identi- 
fication and  valuation.  Some  crucial  irems  of  information 
are  needed  to  properly  complete  this  phase.  As  previously 
menticned,  a  complete,  up-to  date  list  of  all  computer 
system  assets  is  required.  The  Computer  Council  is  tasked 
with  maintaining  an  inventory  of  all  hardware  assets 
(Ref-  38]-  They  should  be  able  to  provide  the  necessary 
information    in    this    area.      Complet-aness    and   accuracy    ar?   the 
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ASSET    IDENTIFICATION                  | 
AND    VALUATION                                1 

}, 

1                           THREAT    AND                                | 
1           VULNERABILITY    EVALOATION          1 

i 

1              ANNOAL    LOSS    EXPECTANCY             ( 

1 

EVALUATION    AND    SELECTION    OF 
ADDITIONAL   C OUNTERME AS URES 

Figure   4.1        Majox   Steps    of   Method   I   Risk    Assessment. 

kays  to  the  succass  of  ths  risk  assessnisn-.  Otherwise,  the 
possibility  exists  tha~  some  piece  of  ADP  equipmenr  r.o- 
lisxed,  and  so  not  considered  in  the  risk  assessman*,  iDay 
somehow  interact  with  equipment  thar  is  consiisred.  The 
thraat  and  the  associated  loss  may  invalida-e  -he  assess- 
ments  made    previously  on    related    equipment. 

The  other  elamenta  crucial  to  this  phase  are  the  inpact 
value  ratings.  The  risk  assessment  ream  will  determine  the 
impact    value  ratings.  The    ADP    Securmy    manual      giv^s   seme 

general  guidance  for  assigning  these  values.  Since  the 
major  purpose  of  a  risk  assessment  is  -o  provide  a  quantita- 
tive base  for  evaluating  the  cost-effectiveness  of  counter- 
measures,  the  importance  of  these  values  cannot  be 
overstated.  Primary  input  for  the  values  associated  with 
hardware  and  software  can  probaoly  be  provided  by  the 
computer   center    staff. 
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Thers   are      four    typas      cf    irapacxs      for    which      each    asset 
musx    ta    evaluated.       These  impacts   are: 

1)  Modification 

2)  Destruction 

3)  Cisclosure 

<4)  Denial  of  service 
The  ADP  Security  manual  provides  a  concise  defini-ticn  of 
these  impacts.  Each  asset  must  be  evaluated  with  respect  to 
these  itsms.  If  an  impact  affects  an  asset,  then  a  monetary 
value  reflecting  that  effect  should  be  assigned.  The  impact 
value  rating  is  associated  with  the  monetary  value.  This 
stage  will  require  close  coordination  between  the  students 
evaluating      the    assets      and    those      members   cf      the    team      who 
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Figure  U.2        Sensitive   Data  7alue   Guidelines. 

determine  the  asset  impact  value  ratings.  Thi  AD?  Security 
Manual  provides  guidelines  for  the  impact  of  disclosure  of 
sensitive   data.      These   values   are   listed   in    figure    4.2. 

There    are   standard   forms    which      should    be   used   to    record 
the    asset      impact   and     valuation    studies.  The    appropriate 

form  for  this  phase  is  designated  OPNAV  5239/7.  An  example 
cf   this    fcrm  is    provided   in    Appendix    I. 
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C.       THREAT    AND    VOLNEBABILIT I    EVALUATION    PHAS3 

Tfce  next  phase  in  the  risk  asssssm&nt  process  is  rh^ 
threat  and  vulnerability  evaluation.  According  to  -h^j  meth- 
cdolcgy,  all  threats  must  be  evaluated  -o  estimate  how  often 
a      "successful"      attack      may        occur.  By      definition,        a 

"successful"  attack  is  one  tha-  resulrs  in  a  definite 
adverse    impact    on  the  activity. 

This  phase  will  also  require  a  grea-  deal  of  ccmiaunica- 
tion  between  the  members  of  the  risk  assassmt^nt  -earn  and  the 
staff    of   the  computer  center.  For    certain   threats   such   as 

power  outages,  the  frequency  rating  could  oe  determined  by 
examining  historical  data.  Hcwever,  input  from  the  computer 
center  staff  may  prove  valuable  when  attempting  to  determine 
frequency  ratings  for  threats  which  ar^  highly  technical, 
such      as   errors      in    the     operating     system    software.  Each 

threat  must  be  evaluated  with  respect  to  the  same  four 
impact  areas  as  the  assets,  that  is,  modification,  destruc- 
tion, disclosure,  and  denial  of  service.  For  certain 
threats  which  have  never,  and  hopefully  will  never,  occur 
there  may  be  some  difficulty  in  assigning  threat  frequen- 
cies. There  is  no  sound  statistical  base  for  assigning 
probatilitirs  to  human  behavior  prooleras.  One  method  to 
approach  this  problem  is  to  use  the  Delphi  technique.  This 
raethcd  involves  having  different  individuals  evaluate  a 
particular  probability  several  times  to  reach  a  consensus. 
This  technique  should  provide  a  probability  estimate  which 
may    offset    the    lack    of  a    human   experience    base.       [Ref.    U1  ] 

A  great  deal  of  time  and  effort  will  be  required  during 
this  phase.  The  more  imagination  which  is  applied  to  devel- 
oping the  threats  and  their  potential  adverse  effects,  the 
more  accurate  the  final  risk  assessment  will  be.  As  a 
result,  the  product  will  serve  its  purpose  and  hopefully 
enhance    AEP    security. 
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The  ADF  Security  manual  provides  a  list  cf  sev-sral 
example  threats.  However,  this  list  is  certainly  not  all 
inclusive.  Threats     which      ara   particular     to      the      Naval 

Postgraduate  School  computer  system,  such  as  the  vulner- 
ability cf  the  back-up  power  supplies  and  its  location  on 
the  flight  paths  of  the  Monterey  County  Municipal  Airport 
must  be  considered  .  The  scope  of  this  risk  assessment  is 
all-enccmpassing.  Much        imaginative      thinking        will     be 

required  during  this  phase  of  the  undertaking,  however,  the 
payoff  ii:  terms  cf  usable  output  should  make  it  worthwhile. 
The    threats      should    be      defined   to      minimize   overlap.  The 

reason  for  this  concern  is  generated  by  the  method  of 
computing  the  annual  loss  expectancy,  which  will  be 
addressed   in  the  next   step    of   this   phase. 

The  threat  and  vulnerability  evaluations  should  also  be 
documented   en      standard    forms.  kr.    example      of    this      form, 

OPNAV  5239/8,  is  enclosed  in  Appendix  I.  The  information 
that  should  be  described  for  each  threat  includes  a  general 
narrative  about  the  threat.  Examples  or  the  threat  should 
be  listed  and  any  counter  measures  which  are  currently  in 
effect  should  be  noted.  Also,  any  unique  circumstances  of 
the  command  which  might  contribute  to  the  threat  should  be 
discussed. 

As  with  th*  previous  phase,  this  portion  of  the  risk 
assessment  could  also  serve  as  a  thesis  project.  Again, 
however,  it  must  te  emphasized  that  close  coordination 
between  the  risk  assessment  team  and  the  computer  center 
staff  is  necessary  to  ensure  that  every  potential  threat  is 
considered  and  that  every  frequency  rating  represents  a 
realistic   estimate. 

Aftar  completing  the  asset  valuation  and  threat  evalua- 
tion phases,  the  next  step  is  to  compute  the  annual  loss 
expectancy  values  (AIE) .  This  step  provides  the  quantita- 
tive     results   which      will   be      used      to    evaluate      addititonal 
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security  measures.  The  ADP  Securiry  manual  describes  a 
mechanical,  fairly  straight-forward  procedure  to  dsxermine 
these   figures.  The   impact      dollar    value      ratings   and      the 

successful  attack  frequency  ratings  interact  to  produce  an 
annual  loss  expectancy  figure  for  each  of  the  four  impact 
areas.  The  individual      ALE   values      for    each     asset    in     an 

impact  area  and  the  individual  ALE  values  for  each  threat  in 
an  impact  area  should  be  added  to  produce  a  total  ALE  value 
for    each      respective   impact    area.  Summing   the      ALE   values 

ever  the  four  different  impact  areas  results  in  the  total 
ALE    value    for  the   system. 

As  stated  in  the  AD?  Security  manual,  the  ALE  "repre- 
sents a  quantitative  estimate  of  the  potential  average 
yearly  financial  less  resulting  from  the  modification, 
destruction,  disclosure  of  data,  or  denial  of  services 
because  of  existing  vulnerabilities  which  may  perra:Lt  identi- 
fied threats  to  be  realized."  [Bef-  39]  Oni  can  see  that 
the  types  of  results  which  are  derived,  namely,  quantitative 
figures  cf  annual  Ices  expectancy,  are  based  totally  upon 
the  estimates  made  in  earlier  phases.  For  the  ALE  figures 
to  be  meaningful,  it  is  clear  that  a  great  deal  of  care  must 
be  taken  to  develop  reasonable  asset  valuations  and  impact 
area      dollar  ratings.  Also,         tne      threat   evaluation      and 

successful  attack  frequency  must  be  consistent  and  not  exag- 
gerate   any    particular   area    without    justification. 

D.       EVALUATION    AND    SELECTION    OF    ADDITIONAL    CODNTERMEASOEES 

After  the  annual  loss  expectancy  values  have  been  calcu- 
lated, the  evaluation  of  additional  countermeasures  can  be 
conducted.  The  procedure  involves  determining  whether  the 
additional  countermeaures  would  benefit  the  overall  security 
posture  and  result  in  a  decrease  in  the  annual  loss  expec- 
tancy     value.  Cost-effectiveness      is        the      criteria      for 
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decision- ma  king  when  considering  any  additional  coun-era-sa- 
sur2s.  Essentially,  avery  count armeasurs  must  be  svaiuated 
to  determine  if  the  redaction  in  the  ALE  is  greaxer  than  the 
cosu  of  installation  and  implementation.  Counrermeasures 
may    be      directed   against      specific  threats.  Some   software 

countermeasures  include  the  establishing  of  audit  trails, 
the  use  of  unique  password/authenzicaiiion  processes,  and  the 
imposixioE  of  some  type  of  residue  ccnxrol  to  clear  sensi- 
tive information  which  the  operating  system  allows  to  remain 
in  resource  sharing  storage.  some  hardware  counzermeasures 
include  the  emplcymentof  protec-icn  stata  variables,  memcry 
protection  lechanisms,  and  the  use  of  interruption  resistant 
power  supplies.  These  are  merely  a  few  examples  of  counter- 
measures  vihich  can  be  utilized  zo  iaprcva  security.  They 
may  be  such  that  the  successful  frequency  attack  ratings  in 
several   iirpact    areas    are   affected. 

The    procedure   for     evaluating   additional   coun termeasures 
consists   of    six    steps: 

1)  Ccuntermeasures  which  can  reduce  the  vulnerabilities 
cf  those  assets  which  currently  have  the  higher  annual 
loss    expectancy    values    should   be    considered    first, 

2)  The  vulnerabilities  which  would  be  reduced  or  elimi- 
nated by  implementing  additional  ccuntermeasures  shculd 
be    identified. 

3)  Assuming  that  the  ccuntermeasure  is  implemented,  the 
projected  successful  attack  frequency  ratings  for  each 
area   should   be    listed, 

4)  A  projected  ALE  for  each  threat  affected  by  the 
ccuntermeasure    should    be   calculated    by   impact    area. 

5)  The  projected  ALE  should  b^  subtracted  from  the 
current  ALE  to  show  the  savings  possible  by  imple- 
menting the   proposed  ccuntermeasure. 

6)  The  ALE  savings  in  each  impact  area  should  be  summed 
and  then  divided  by  the  annual  cost  of  the  ccuntermea- 
sure  to  get  the    Return -on-Investment     (EOT).       [Ref.    42] 
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Again,  thazs  is  a  specific  form  provided  to  psrform  -thsse 
calcula-^icns.  An  axampl's  of  zhis  fori,  OPNAV  5239/10,  is 
givan   in    Appendix   I. 

The  Eeturn-cn-InvesiiDent  figure  is  important  in  the 
selecticn  of  which  additional  couatarmeasurs  to  iirplement. 
This  salection  process  occurs  in  an  incremental  fashion.  As 
countermeasures  are  implemented,  they  affect  the  overall 
security  posture  of  the  entire  computer  center.  This  effsct 
is  realized  in.  a  different  ALS  valua.  Since  changes  in  the 
ALE  will  cause  a  corresponding  change  in  the  ROI  for  a 
particular  coun term^asure,  the  co untermeasures  must  be 
considered    singly. 

The  countermeasure  with  the  highest  ROI  is  considered 
first.  Then,  the  countermeasure  with  the  next  higher  ROI  is 
evaluated  with  the  new  ALE  resulting  from  implementation  of 
the  previous  countermeasure.  This  procedure  is  continued  as 
long  as  the  respective  ROI  remains  greater  than  one.  The 
countermeasuras  with  R0I*3  greater  than  one  may  be  ranked 
according   tc  their    respective   values.  A   plan   to    iitpl'rment 

these  countermeasuras,  within  budgetary  limitations,  may 
then    te    determined. 

The  situation  may  occur  where  higher  authority  directs 
that  certain  countermeasures  be  implemented.  In  that  case, 
these  countsrmea sures  may  take  priority  for  implementation 
regardless   of  their    ROI. 
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V,  iOlOMATED  ¥S-  MANUAL  RISK  ASSESSMENT  SYSTEMS 

A.   GENEEAL 

At  this  time,  no  automated  cz  computerized  risk  assess- 
ment mexhcdclogy  has  been  approved  for  use  by  agencies  of 
the      Federal  Sovernmer.i:.  This      is      no   reflect-ion      on      the 

Government's  lack  of  interest  or  distrust  in  the  product;  it 
is  more  a  matter  of  an  extremely  limited  market  -  thsre  are 
less  than  a  handful  of  risk  assessment  software  packages 
currently   available. 

One  of  the  few  companies  in  private  industry  involved  in 
developing  risk  assessment  software  is  Pansophic  Systems, 
Inc.,  cased  in  Oak  Erook,  Illinois.  Among  the  sof-^ware 
security  products  the  company  offers  are  :  Panaudit,  a  tool 
that  can  be  used  for  ADP,  financial,  and  statistical 
auditing  cf  computer  systems;  Panexec,  which  can  be  us=d  for 
auditing,  control,  backup,  and  recovery  measures;  and 
Panrisk,  an  automated  risk  assessment  system  for  management 
planning.  Advertisements    for      Panrisk      boast      that    it      is 

"...the  first  system  ever  to  show  where  to  direct  your 
computer  security  efforts  with  quantifiable  certainty" 
[Ref.    43]. 

Although  the  Panrisk  system  works  under  the  same  basic 
framework  as  the  manual  methods  advocated  within  the  DOD,  it 
has  a  majcr  drawback  that  greatly  limits  its  usefulness  and 
applicability  to  government  computer  facilities.  It  is  only 
compatible  with  IBM  operating  systems.  However,  if  Panrisk 
had  shown  any  degree  of  success  in  the  market,  ether 
computer  vendors  would  have  undoubtedly  developed  similar 
systems    for    Honeywell,    Burroughs    and    others. 
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According  tc  its  advsrrising  brochure,  "Basically, 
Panrisk  is  ths  application  of  a  simpla  formula  to  a  variety 
of  rhreats  whose  results  are  aggregated  -o  give  a  complste 
picture  cf  an  organization's  total  loss  potential  ov?r  a 
period   of  time    "   [Ref.   US].  rha  siapla    formula    for   calcu- 

lating the  Annual  Less  Expectancy  ALS  is  the  same  as  that 
given  in  FITS  PUB  65,  although  the  terminology  used  differs 
somewhat: 

ALE   =   single  occurrence   loss   x   occurrence   rate 

ie.    impact   x    frequency 

Skeptics  might  rightfully  question  using  a  computer 
system      for   such      a    calculation.  Panrisk   does,         however, 

produce  outputs  beyond  a  simple  ALS  -  it  can  format,  edit, 
and  generate  various  reports  en  risk  information  to  be  used 
at  all  levels  within  an  organization.  Tnus  the  package  may 
have  seme  merit  in  its  use  as  a  aanagement  Information 
System  (MIS)  or  as  a  Decision  Support  System  (DSS) .  The 
problems,  though,  arise  in  the  input  requirements.  In  order 
for  the  system  to  become  useful,  the  organization  must 
provide  the  information  on  its  computer  resources,  threat 
probabilities,  vulnerabiliti.es,  and  loss  potentials.  The 
provision  of  such  inputs  constitutes  the  most  difficult  part 
cf  conducting  a  risk  assessment.  Since  such  inputs  are 
largely  based  on  intuition  and  experience,  it  could  not  be 
expected  that  an  automated  system  would  be  able  to  produce 
them.  In  general,  therefore,  tne  larket  for  an  automated 
risk  assessment  will  be  extremely  limited.  In  the  fall  of 
1982,  Panrisk  was  taken  off  the  market  for  an  indefinite 
period   of   time. 

In  short,  an  automated  system  is  no  better  than  a  manual 
one      on      the  input      side      of      the   Risk      Assessment      process. 
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Furthermcra,  organizations  must  sxercise  caution  in  consid- 
ering buying  off-the-shelf  Risk  Assessment  software,  since 
Rislc  Assessments,  by  their  very  natire,  must  be  uniquely 
tailored   to     an    agency's   needs.  From    the  standpoint      of   a 

ESS,  however,  an  automated  aisk  Assessment  could  greatly 
facilitate  a  user's  understanding  and  ability  to  handle 
budgeting   and  security  problems. 

B.        A    RISK    ASSESSMENT    AS    A    DECISION    SOPPORT    SYSTEM 

An  automated  Risk  Assessment  could  serve  as  an  excellent 
application  for  a  Decision  Support  System  (D3S)  .  According 
to  Sprague  and  Carlson  [Ref.  44]  the  characteristics  cf  an 
effective  DSS  include  :  1.)  Support  for  unstructured  (or 
semistructured)  problems;  2.)  Support  for  all  levels  of 
decision-iaking ;  and  3.)  a  combination  of  analytical  techni- 
ques and  data  presentation  techniques.  A  Risk  Assessment 
application   should    include    all   of   these    characteristics. 

Sprague  and  Carlson  [Ref.  44]  discuss  three  components 
that  make  up  a.  DSS  :  1.)  the  dialog  model,  vhich  serves  as 
the  user  interface  tc  the  system;  2.)  the  data  modal,  which 
controls  and  monitors  the  systsm  data  bases  via  a  data  base 
managemsnt  system  (OEMS)  ;  and  3.)  the  modeling  component, 
which  interfaces  with  the  data  and  dialog  models  tc  perform 
mathematical  and  analytical    operations. 

The  dialog  component  of  a  DSS  is  perhaps  the  most  impor- 
tant since,  from  the  user's  point  of  view,  it  functions  as  a 
virtual  system.  Th?  dialog  component  must  be  able  to 
support  a  variety  cf  presentations  and  output  devices, 
different  inputs,  dialog  styles  and  communications,  and 
above  all,  must  be  user  friendly.  [Bef.  44]  For  a  Risk 
Assessment  application,  *his  means  that  the  user  (possibly 
the      ccmniand's    Security     t^anager      or      ADP   Security      Officsr) 
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shoald  ]:<=  afcl*  tc  selecz  the  way  in  which  he  in  puns  zc  th9 
system  and  the  way  in  which  cuxpuns  are  displayed  on  the 
terminal  cr  printer.  Inpats,  which  may  include  kry beard 
inputs,  jcysticks,  function  keys,  ate,  will  be  constrained 
by  th€  available  hardware,  but  outputs  can  have  several 
options,  largely  software-supported,  which  will  only  be 
constrained  by  the  user's  and  builder's  imaginations  and 
abilitiss.  Users  may  request  that  the  dialog  conventions 
used  include  question/answer  sessions,  menu  selections, 
graphical  displays,  and  HELP  facilities  to  aid  in  supporting 
the    user's    knowledge    base. 

Th€  data  cotnponent  should  be  able  to  support  a  variety  of 
data  structures  and  types,  while  allowing  for  easy  data 
access  and  retrieval  [Ref.  44].  This  will  require  an 
extremely  versatile  and  capable  DBMS,  but  the  current 
state-of-the-art  is  such  that  these  requirements  could  be 
met  by  a  system  as  simple  as  DBASE  II  which  is  available  on 
most  micrcccmputers.  The  DBMS  of  a  Risk  Assessment  applica- 
tion will  require  that  the  user  be  provided  capabilities  tc 
generate,  update,  and  maintain  data  bases  composed  of,  at  a 
minimum,    threat,    asset,    and    vulnerability    information. 

The  ircdeling  ccmponent  must  provide  a  Model  Base 
Management  Sys-em  (MEMS)  to  allow  for  the  building  and  crea- 
tion cf  new  models,  model  manipulation,  and  the  management 
of  a  library  of  models  [Ref.  44].  The  models  in  a  Risk 
Assessment  CSS  will  te  used  to  calculate  ALZs  for  impact  and 
threat  categcries,  ccnpare  various  AL2s,  and  mathematically 
combine  and  naniculate  ALE  figures.  This  component  cculd  be 
handled    ty    the    programming    capabilities    of    D3ASE    II. 
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C.        DESIGN    SOGGESTIONS    FOR    A    DECISION    SUPPORT    SYSTEM 

1 .      The    Pi  a  1  eg    Ccmponen  t 

This  componen-t  should  initially  allow  th^  user 
sevaral  presentation  options,  and  should  be  buii*  such  that 
later  refinements  and  enhancements  can  be  made  with  r=lazive 
ease.  As  the  user  becomes  familiar  wit.h  th9  system  and 
feels  comfortable  in  using  it,  he  may  want  to  reduce  the 
syszem^s  HELP  facilities  in  favor  of  more  speed  and  flexi- 
bility. Initially,  however,  the  user's  knowledge  base  will 
be  small  and  he  will  prefer  to  be  "led  through"  the  system. 
Assuming  the  user  is  at  Isast  familiar  with  how  to 
initialize  the  system,  turn  the  terminal  on  and  logon,  he 
will  then  need  to  know  how  to  make  a  call  to  the  Pisk 
Assessment  DSS.  This  should  be  as  simple  a  type-in  as 
"Begin  Risk",  "Co  Risk",  or  "Risk"  followed  by  a  carriage 
return.  Ihe  initial  screen  might  look  like  the  one  shewn  in 
figure    5,1.  An   additional   option      might    involve      moving  a 

cursor  celcw  the  desired  operation  using  a  joy  stick,  or 
selecting  the  operation  with  a  light  pen.  Once  an  operation 
is  selected,  a  new  screen  showing  additional  options  within 
that  operation  will  be  displayed.  All  screens  beyond  the 
initial  one  will  provide  "Help"  options  as  well  as  options 
to  return  to  the  main  menu  or  end  the  session.  The  dialog 
model  might  also  present  the  user  with  a  canned  list  of 
assets,  threats,  and  vulnerabilities,  such  that  he  could 
delete  these  that  were  inapplicable  to  his  organization,  and 
add  those  that  did  apply.  This  would  not  only  serve  to 
increase  his  knowledge  base,  but  would  also  prevent  a  lot  of 
unnecessary   terminal   work. 

Output  representations  from  the  operations  should 
come    in    a    variety   of    formats.         Bar    graphs    might    prove    to   be 

desirable   representations      since   the    user    may      want   ccmpari- 
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RISK    aSSHSSMSNT    DBS 

select   tha  desired  operation   by  typing   the  corresponding 
number    followed    by  a   carnage    return. 


1. 

2. 
3. 

4. 
5. 
6  . 


Database    Update/Modification 

Display    a  lisz  of   computer   system   asse-s 

Display    a  list   cf   conipu-cer  rhrears 

Display    a  list   of   computer   vulnerabilities 

Calculate   Annual    Loss   Expectancy    (ALE)     values 

End    Session 


WAITING    : 


Figure   5.1        Initial   Screen   for  a    Risk   Assessment   DSS. 

sons  cf  various  ALSs  at  differen-  periods  of  time.  Figure 
5.2  illustrates  the  type  of  output  representation  that  niigh- 
be  provid=d  by  a  Risk  Assessment  DSS.  Siailar  output  repre- 
sentaticns  could  be  constructed  for  the  other  impact  areas 
as  well  as  for  threats,  assets,  and  vulnerabilities.  For  a 
DSS  cf  this  type,  most  users  will  desire  outputs  that  show 
comparisons  cf  relevant  information.  A  prioritized  list  of 
vulnerabilities,  for  example,  would  show  which  vulnerabili- 
ties   are    the   most  costly   in    terms   of    ALils. 

2 •      Ihe    Cat a   Com  pcnent 

The  Data  Compcnent  will  oe  perhaps  the  most  diffi- 
cult to  understand  and  manage.  A  viable  and  capable  Data 
Base  Management  System  (DBMS)  will  be  required  to  maintain 
the  vast  number  of  files,  the  large  sizes  cf  the  files,  and 
the  links  between  the  files.  In  general,  an  effective  DBMS 
should   result      in   reduced      costs   of      building   and      using   the 


72 


D<=struction    Impacr 

Area 

ALi         -100 

I 

-eo 

■♦• — -»- 
1 

-60 

+— + 

♦  --+ 

+  --  + 

-40 

1 

1 

-20 

1 
1 

i 

0 

♦  — 

1 

1 

1 

1979               1980 

198" 

1 

1982 

NOTES:    Ths 

ALE 

OF    $60K  in    1979   rep 

resents 

the    value 

calcalat =d 

for 

the   comple-icn   ct    z 

he    01 

:iqi 

nal    ALE. 

Du€   -:c    the 

additicn  of"  the   Hiqn   Sp 

eed   Communications           j 

System   in   1980, 

rhe  increase   m   sy 

stem 

vul 

nerabilities 

brcughx    abo 
$80Kf  . 

at   a    proportionate   mcr 

ease 

in 

the    ALE    (to 

Installed  coun-t 

.ermeasures   lowered 

the    ALE 

TO    3  50K    in 

1981.    This 

status    was   retained   zhi 

0  u  g  a 
ALE 

198 

9. 

Exisring    pi 

ans 

should    decrease  -he 

TO 

$45K    by    1983. 



Figure  5.2    Bar  Graph  Output  Hepresentation. 

DSS ,  increased  data  control  and  sharing,  and  reduced  data 
redundancy.  [Ref.  a5]  In  building  the  DBHIS  for  a  DSS,  the 
designer  will  chose  a  data  model,  whicn  is  a  "methcd  of 
representing,  organizing,  storing,  and  handling  data  in  a 
computer"  [Ref.  46],  The  three  parts  comprising  a  data 
model  include  :  1.)  a  collection  of  data  structures;  2.)  a 
collecticn  cf  ocerations  that  can  be  applied  to  the  data 
structures;  and  3.)  a  collecticn  of  integrity  rules  that 
define  the  valid  states  for  the  structures.   [Ref.  46] 

The  data  structures  for  a   Risk  Assessment  will  vary 


depending  on  the  type  of  file, 


Separate  files  will,   at  a 


minimum,   be  required  for   computer  assets,    threats,   and 
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vulnerabilities.  Figure  5.3  shows  the  fields  tha-  migh-  be 
contained  in  such  files.  Such  a  field  sxructure,  however, 
will  obviously  result  in  a  great  deal  of  data  redundancy. 
For  example,  one  asssT  will  be  exposed  to  several  threa-s; 
conversely,  one  threat  may  affact  several  assets.  The  mcst 
wasteful  method  would  be  to  list  every  threa-  affec-ing  a 
specific  asset  and  include  them  as  part:  of  a  record  in  zhe 
assex  file.  Similarly,  every  asset  affecTed  by  a  specific 
threat  wculd  be  included  as  part  of  a  record  in  rhe  threat 
file.  A  more  logical  method  of  constructing  these  files 
would  be  to  link  the  records  in  each  file  together  using 
some  type  of  relational  data  base  model  with  primary  and/or 
secondary    keys. 

fcithin  the  data  model  it  will  be  necessary  to  define 
a  r elaxicnship  between  the  asset  and  threat  files  such  that 
it  can  be  determined  which  assets  are  affected  by  which 
threats,      and      within  which    impact  categories.  The    fields 

used  for  this  relation  will  be  the  IMPACT  CATEGORIES (4 )  in 
the  asset  file,  and  the  IMPACT  CATEGORIES  AFFECTED  (U)  in  the 
threat  file.  By  defining  this  relation,  it  will  be  possible 
to  select  a  specific  asset,  link  it  to  an  applicable  threat, 
and      calculate    the       ALE.  This    type      of      linkage    coaid      be 

performed  by  a  JOIN  operation.  According  to  Kroenke,  "The 
JOIN  cparation  is  used  to  combine  two  relations.  A  value  of 
cne  attribute  in  the  first  relation  is  compared  with  a  value 
of    an      attribute   in    the   second.  If    tne   two   values      have   a 

relationship  specified  in  the  join  operation,  then  the 
tuples  of  the  relations  are  combined  to  form  a  third  rela- 
tion." [Bef-  50]  Thus,  an  asset  record  and  a  threat  record 
can    be    "jcined"    by    issuing    a   command    such    as: 

ASSET  (IMPACT   CATEGORTf  (4)  =IJ1FACT    CATEGORY  (4)     AFFECTED)  THREAT 
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where  the  value  of  the  IiilP  ACT  CATEGORY  field  in  -he  assst 
file  is  ccmpared  to  the  IMPACT  CATEGORY  AFFECTED (4)  fi^ld  in 
the  thraat  file.  If  the  values  of  -he  two  fields  are  equal, 
then  the  two  records  can  be  combined  re  form  a  single 
record.  In  this  way,  it  can  be  determined  that  the  record 
resulting  from  -he  JOIN  operation  con-ains  an  asset,  an 
applicable   threat   frcm  a   specific     impac-    category,      and  the 


ASSET    FILE   : 

asse-    r.ame/asset    categor  y/descript  ion/impact   categories 
(U)/iiDfact  category  costs(4)/ 

THREAT    FILE: 

threat    name/descriptLon/iiapact   categories    affected  (U)/ 

frequency  of    occurrence/ 

VOLNEEABILITI    FILE: 

vulnerability   name/descr iption/thr eats    exploiting/ 

COONTEEMEflSORE   FILE: 

countermeasur e   name/description/cost    of    implementing/ 
vulnerabilities   a f fecting/-hreat    frequencies 
af fectinq/ 


Figure    5.3        Field    Layout   for   Required   Files. 

frequency  of  occurrence  for  that  thr=at.  The  ALE  can  then 
be  calculated  by  multiplying  the  impact  value  times  the 
threat    jrcbability. 

The  operations  that  will  be  applied  to  the  data  base 
files  should  include,  but  not  necessarily  be  limited  to, 
retrieval,  update,  modification,  combination,  and  summation. 
The  dialog  component  should  prompt  the  user  for  the  desired 
operation,  while  allowing  him  to  specify  such  details  as 
file    rame,    field   name,   etc. 

The  integrity  rules  for  the  field  values  in  the 
files    may      be   kept      relatively    simple.  Values    for      impact 
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catigcry  oiay  easily  be  constrained  to  the  four  categories  of 
destruction,   modification,  disclosure,        and        denial-cf- 

service.  Numeric  values  may  be  limited  to  a  relatively  wide 
range      of      values      within      certain      limits.  For      example, 

frequency  ratings  for  threats  may  contain  any  decimal  value 
between  .COO  and  .999.  ALE  values  for  the  destruction  cate- 
gory will  be  equal  to  the  asset  replacement  cost.  By  the 
same  token,  no  asset  ALE  may  exceed  its  total  replacement 
cost . 

3  ,      I  he    Modeling    Compon  ent 

"The  modeling  component  is  the  primary  tool  for 
supporting  many  of  the  activities  that  decision  makers  will 
perfcrm  in  the  process  of  making  decisions  and  solving  prob- 
lems" [Ret.  47].  The  decisions  and  problems  for  a  Risk 
Assessment  application  will  evolve  about  the  calculation  of 
ALEs,  and  determining  the  areas  where  the  greatest  ALE 
reductior  can  occur.  Thus,  a  library  of  models,  consisting 
cf  permanent,  ad  hoc,  user-built  and  "canned"  mcdrls 
[fief.  47]  will  have  to  be  made  available  to  the  user.  The 
permanent  models,  these  desired  by  most  users,  might  have 
the  capabilities  shown  in  figure  5.4.  In  addition  to  these, 
model  generators  should  be  at  the  disposal  of  the  users  m 
crder  that  they  may  generate  and  structure  tneir  own  models. 
Optional  models  that  may  be  requested  involve  activities  for 
projection,  deduction,  analysis,  creation  of  alternatives, 
ccmpariscn  of  alternatives,  optimization,  and  simulation. 
[Ref.    48] 

^ •      Integration    cf  Como onents 

"The  modal  base  and  its  management  system  must  be 
integrated  with  the  dialog  direct.ly,  to  give  the  user  direct 
control  over  the  operation,  manipulation,  and  use  of  models" 
[fief.    49].  3y   the      same      token,      there      must      be    a      tight 
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THREAT    aCDEL     : 

a~caIcuIa-cion ,    sunnDanion ,    and   analysis    of    the    ALEs 

contributed    to   by   specific   threats 

ASSET    KOCHj     : 

tlie  Ills   attributed  to   specific  assets. 

VDINEB ABILITY    MODEL    : 

an   analysis    an^^percenta ge   calculation   of   the    ALEs 

caused   by  specific   vulnerabilities. 

COUNTEEMEASURE    MODEL    : 

an'analylis    of  fSenfLE  reductions    that    might    be    brouaht 

abcut    by   the    implementation    of   specific    counteraeasufrs. 


Figure    5.4        Permanent   Model   Capabilities. 

coupling  between  the  modeling  component  and  the  data  compo- 
nent. "With  this  direct  linkage,  models  can  be  updated  as 
the  data  values  are  updated,  and  modified  or  restructured 
when  the  data  have  changed  enough  to  require  it"  [Ref.  49]. 
The  components  and  the  possible  linkages  among  them  may  be 
depicted    as    in    figure   5.5. 
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D-       LIMITATIONS 

The  ccnstruction  and  design  of  -hs  dialog  and  modaling 
compcnen-ts  can  be  made  with  relative  ease.  It  is  in  the 
design  and  development  of  the  data  componen-!:  that  the 
majority  cf  the  difficulties  will  arise.  This  will  cr=ate 
additional  problems  in  that  a  compla-ce  and  capable  DBMS  is 
critical  tc  the  correct  functioning  of  rhe  dialog  and 
modeling  components.  The  DSS  can  not  function  without  the 
complete    integration    cf   rhe    rhree  components. 

The  user  is  also  ccnfronned  with  severe  difficulties  in 
the      actual     construction      of      the      databases.  While      the 

designer  may  be  able  t.o  provide  an  efficient,  mechanism 
through  which  databases  may  be  created  and  updated,  the  user 
may  be  frustrated  in  his  attempts  to  collect  ~he  data  needed 
tc    include    in  the   databases. 
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VI.     CONCIOSIONS    AND    RECOHMENDATIONS 

This  -chesis  has  examined  various  facets  of  -he  concepts 
cf  risk  assessment.  The  subject  is  exceedingly  complex  and 
affects  virtually  all  segments  of  organiza-ion^  which  employ 
computers  tc  accomplish  their  objectives.  The  multitude  of 
directives  promulgated  by  various  agencies  of  -he  federal 
government  attest  tc  the  attention  being  focused  en  risk: 
assessments.  The  quality  of  the  direction  provided  in  this 
area  is  generally  good;  however,  che  instructions  are  often 
lengthy  and  sometimes  written  in  a  style  difficult  to 
follow.  The  most  iiportant  point  expressed  in  Chapter  Two 
is  the  realization  that  competent  guidance  concerning  risk 
assessments  exists.  The  level  of  user  awareness  regarding 
the  availability  of  this  guidance  must  be  raised.  As  the 
federal  government  in  general,  and  the  Department  of  the 
Navy  in  particular,  allocate  more  and  more  funding  to 
computer  systems  resources,  organizational  dependence  upon 
computer      services    will      grow.  This      fact    necessitates      a 

corresponding  effort  towards  ensuring  tha  security  of 
computer   systems.  For    example,         the    Naval      Regional   Data 

Automation  Center,  San  Francisco  (NASDAC-SF)  allocated 
several  personnel  in  its  Management  Control  Department  to 
conduct    a      risk    assessment    at      that    facility.  Their    study 

resulted  in  a  total  annual  loss  expectancy  for  NAEDAC-SF 
amounting  to  over  S8.8  billion.  It  should  be  noted  that  an 
astronomical  figure  like  S8.8  billion  in  no  way  represents 
the  actual  expected  value  of  losses  during  a  given  year. 
Father,  it  is  the  aggregate  ALE  resulting  from  totalling  the 
individual  AL2  *  s  in  each  impact  area.  These  figures  indi- 
cate the  relative  priorities  to  be  placed  on  security 
measures   in     different  areas.        Clearly   assets     evaluated   at 
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relative  cums  of  this  magnitude  warrant  significant  S'^curity 
appraisals.  This  attention  and  analysis  is  precisely  the 
driving  influence  behind  the  rislc  assessment  directives. 
Further  dissemination  to  the  proper  individuals  with  appro- 
priate authority  should  increase  security  efforts  in  this 
area. 

Several  aspects  associated  with  contracting  for  risk 
assessment  services  were  considered  in  Chapter  Three. 
OPNAVINST.  5239.  1A  directs  all  commands  with  computer  system 
assets  to  conduct  a  risk  assessment.  The  amount  of  effort 
required  to  conduct  a  risk  assessment  may  force  smaller 
commands  to  seek  outside  assistance.  Naval  Regional  Data 
Automation  Centers (NABDACS)  are  available  to  provide  assis- 
tance. However,  the  various  NARDAC's  around  the  country  are 
staffed  at  different  manning  levels,  so  the  amount  Df  assis- 
tance each  command  is  aole  to  provide  may  vary.  CCMNAVDAC 
maintains  a  list  of  contractors  approved  to  conduct  risk 
assessments  or  t c  provide  assistance  to  commands  conducting 
their    own    risk    assessments. 

As  the  framework  for  conducting  a  risk  assessment  at  the 
Naval  Postgraduate  School  demonstrates,  the  task  of  actually 
conducting  one  is  certainly  non-trivial.  Compiling  a  list 
of  all  systems  assets  and  procedures  and  assigning  impact 
values  to  them  is  a  complicated  ,  time-consuming  endeavor. 
Of  equal  difficulty  is  determining  a  list  of  all  potential 
threats  and  their  associated  frequency  ratings.  It  requires 
personnel  experienced  in  the  areas  of  computer  operations, 
finance  and  administration.  The  computation  of  the  ar^nual 
loss  expectancy  and  its  use  in  evaluating  the  potential 
benefits  of  counteraeasures  is  also  an  effort  which  requires 
a  great  deal  of  precision  and  judgement.  The  ADP  Security 
Manual  provides  a  reasonably  clear  explanation  of  these 
steps  and  good  background  material  which  is  beneficial.  The 
manual    also    provides    examples    for    each   type    of   ccmputaticn. 
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In  ceneral,  the  emphasis  currently  being  d=vcted  -o 
security  and  risk  assessments  in  the  Navy  is  very  -inely  and 
prudent.  Given  the  dependence  of  the  Navy  on  computer  tech- 
nology fcr  such  services  as  supply  processing,  tracking 
spare  parts  failure  and  usage  rates,  envircnmen-cal  fore- 
casting, payroll  and  personnel  records  and  a  myriad  of  ether 
tasks,  it  is  easy  to  imagine  -he  havoc  which  could  be 
created  if  these  services  are  disrupt-ed.  The  risk  assess- 
ment program  is  a  positive  effort  to  study  the  state  of 
security  with  respect  to  a  command's  computer  systems, 
quanitfying  the  assets  and  threats  and  using  this  data  to 
evaluate  count ermeasures .  The  criteria  for  evaluating  coun- 
termeasures  is  cost-effectiveness.  The  risk  assessment 
procedure  appears  to  te  a  logical  manner  in  which  to  deter- 
mine the  relative  impacts  of  various  threats  on  system 
assets   utilizing  this   criteria. 

It  wculd  be  difficult,  if  not  impossible,  to  quantify 
the    exact      value   of    the      risk   assesment    itself.  Since   the 

overall  purpose  of  a  risk  assessment  is  to  justify  counter- 
measures  in  order  to  prevent  disasters,  hopefully  potential 
disasters  will  be  averted.  Certainly  attention  will  be 
directed  tc  problem  areas  in  security.  However,  even  though 
this  process  has  not  been  quantified,  the  logic  providing 
the    impetus    to    conduct  such    assessments   seems    well-grounded. 

No  prccrdure  in  this  area,  however,  will  be  successful 
unless  it  receives  a  sufficient  amount  of  command  attention. 
The  general  tendency  for  most  commands  is  to  treat  the 
security  and  reliabiltiy  of  computer  services  in  a  "taken- 
for-grant£d"      manner.  The      magnitude        of      the      potential 

disasters  due  to  the  loss  of  computer  services  makes  a 
change  in  this  type  cf  care-free  attitude  imperative.  The 
requirement  directing  all  commands  with  computer  systems  to 
conduct  a  risk  assessment  is  an  important,  ^^iable  means  of 
correctina   this      attitude.         It      forces    commands      to    make      a 
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rational,  thoughtful  analysis  of  its  systems  as  direc-ed  by 
OPNAVINSI  5239. 1A.  To  derive  aaximum  profit  from  ^his 
procedure,  the  command  should  ensure  that  all  concerned 
personnel  are  aware  of  the  significance  of  conducting  this 
exercise.  If  the  risk  assessment  procedure  degenerates  into 
a  "paperwork  drill"  conducted  by  some  personnel  in  the  lower 
levels  of  the  command,  then  the  results  may  be  virtually 
worthless. 


A.       SDGGESTIONS/HECOHHEHDATIONS    FOR    IMPROVEMENTS 

As  mentioned  previously,  the  risk  assessment  at  the 
Naval  Postgraduate  School  can  be  completed  by  students  in 
the  various  Computer  Systems  and  Management  curricula.  This 
situation  would  provide  many  benefits  of  both  an  academic 
and    practical  type,    not   the    least   of    which   ars: 

1)  Provide    participating    students   with   a    fundamental 
knowledge  of   the   computer   security    problem. 

2)  Save  the    Naval  Postgraduate   School    a   consideraoie 
amount    of   money. 

The  remaining  recommendations  are  directed  at  the  larger 
scale  prcblem.  A  measure  which  would  improve  both  the  effi- 
ciency and  effectiveness  of  the  risk  assessment  procedure 
might  be  tc  establish  assist  teams  at  NARDAC's  throughout 
the  country.  These  teams  would  be  availanle  to  assist 
commands  d=siroas  of  conducting  risk  assessments  by 
providing  expertise  in  security  areas  not  normally  encoun- 
tered by  activities  as  part  of  their  norisal  routine.  The 
establishment  of  these  tiams   would   serve   several    purposes: 

1)  Provide    a   body  of  experts   to    conduct    risk 
assessments    and/or    to    provide    assistance   to 
commands   conducting    them. 

2)  Enable    commands   throughout   the    Navy   to   conduct 
their   own   assessments   without    being   forced    to 
contract   for   services. 
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Another  area  which  could  be  improved  is  to  prcvi3e  more 
definitive  guidance  to  commands  concerning  the  value  of 
systeiDS  assets.  Central  agencies  in  Washington,  D.C.  such 
as  the  Autoiratic  Data  Processing  Selection  Of  fice  (ADFSO)  and 
the  Naval  Data  Automation  Command  (N A VDAC)  maintain  approval 
authority  and  inventories  of  major  systems  throughout  the 
Navy.  These  agencies  should  possess  data  concerning  the 
costs  of  various  types  of  hardware,  software,  and  possibly 
data.  The  dissemination  of  this  data  could  eliminate  seme 
of   the   estimating   required    to    get   values   for   systems   assets. 

A  final  recommendation  concerns  the  subject  of  an  auto- 
mated risk  assessment  pacicage.  Chapter  Five  has  presented 
the  preliminary  design  for  a  Risk  Assessment  Decision 
Support  System.  A  feasibility  study,  conducted  perhaps  at 
one  of  the  NARDAC's,  might  be  undertaken  to  assess  whether  a 
DSS  of  this  type  would  be  beneficial  and  cost-effective  on  a 
Navy-wide  basis.  To  satisfy  a  wide  range  of  users,  this  DSS 
would  have  to  be  extremely  user-friendly  and  capable  of 
accepting  a  variety  of  inputs.  It  may  be  that  the  inventory 
of  Navy  computer  systems  is  so  varied  that  this  type  of 
managenient  support  aid  would  not  be  practical  on  such  a 
large  basis.  However,  the  potential  benefits  of  this  tool 
merit   seme    investigation. 
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AEPENDIX  A 
EXAMBLES  OP  7ARI00S  FORMS  USED  IN  RISK  ASSESSMENT 

COMPUTATIONS 

This  is  an  axample  of  OPNAV  5239/7. 


OWAVINST  5?S9  U 


ASSET  VALUATION  WORKSHEET 


I    ASSET  NAME 


2.  ASSET     DESCRIPTION         ANO       JUSTIFICATION      OF       IMPACT     VALUE       RATINGS    ASSIGNED. 
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3.    IMPACT     VALUE      RATING     BY 
□    MODIFICATION 

IMPACT     AREA 

Q    DESTRUCTION 

□    DISCLOSURE    . 

□  DENIAL  OF  SERVICE 

OPNAV    S2J9/7  (2-92) 

This   is    ac  example   of   OPNAV    5239/8. 


WWAVIMST  iZSf.lA 


THREAT  AND  VULNERABILITY  EVALUATION  WORKSHEET 


I.  THREAT    NAME 


2.     DESCRIPTION,  EXAMPLES.  WO   JUSTIFICATIOM     BASED     ON    EXISTING     COUNTERMCASURES     ANO    VUtNERABILlTIES . 


3.  SUCCESSFUL     ATTACK      FREOUENCY     RATING     ST     IMPACT    AREA. 

I      [    MODIFICATION  I       I  DESTRUCTION  j""]  DISCLOSURE  P"!  DENIAL    OF    SERVICE 


OPNAV  S2S9/8  (2-821 
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This  is  an  example  of  OPNAV  5239/10 


OPfUVINST 

ADDITIONAL  COUNTERMEASURE  EVALUATION  WORKSHEET 

5239. !« 

1.   ;    or.fEfMEASURE    NAME                                                                                                                          12.  ANNUAL    COST                                         1 

THREATS   AFFECTED    8Y   THIS     COUNTERMEASURE 


ALE 


PROJECTED 


ALE    SAVINGS 


p.   RETURN    ON    INVESTMENT 


8.    TOTAL 
ALE 
SAVINGS 


9    OVERLAPPING    ADDITIONAL    COUNTERMEASURES 


OPNAV   S239/I0   (2-92) 
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